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ABSTRACT 



A domain communications server having a first computer 
with a disk for storing a dynamic client registry and resource 
locators containing function names; a web server to respond 
to resource locators by calling the function name; a database 
management program for organizing the dynamic client 
registry; a domain communications server which, when 
loaded by the web server is executed to respond to resource 
locators directed to it and to direct the database management 
program in organizing the dynamic client registry; second- 
ary computers communicating with the first computer, the 
secondary computers each having a disk for storing a 
dynamic group registry and for storing resource locators 
containing function names; each secondary computer 
executing a web server which causes it to respond to 
resource locators by calling the function indicated, each 
secondary computer also having a database management 
program for organizing its dynamic group registry; a client 
side communications server executing in each secondary 
computer responding to resource locators directed to it and 
directing the database management program in organizing 
its dynamic group registry; a domain communications 
resource locator list stored in the computers that causes 
functions to be selected for execution in the domain com- 
munications server in the first computer; and a client side 
communications resource locator list stored in the computers 
that causes functions to be selected for execution in the 
client side communications server in the secondary comput- 
ers so communications between the computers cause 
selected functions to be executed to manage information 
flow between them. 
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Fig. 27 



create table DomainClients 
(DCserverName text not null, 
DCactive int not null, 
DCfirmID text not null, 
DCfirmName text not null, 
DCfirmLogo text not null, 
DCsitelD text not null, 
unique (DCserverName), 
unique (DCfirmID, DCsitelD)); 



update tables set table_owner = 'nsadmin' where table_name = 
'DomainClients'; 

Fig. 28 



create table DCCIIentSources 
(DCSfirmID text not null, 
DCSsourceFirmID text not null, 
unique (DCSfirmID, DCSsourceFirmID)); 

update tables set table_owner = 'nsadmin' where table_name = 
'DCIientSources'; 



Fig. 29 



create table DCObjects 
(DCOobject large_object not null); 

update tables set table_owner = 'nsadmin 1 where table_name = 
'DDobjects'; 
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Fig. 30 



create table DCObjectDestinations 
(DCODtarget text not null, 
DCODIoHandle text not null, 
DCODreceived timestamp not null, 
DCODprocessed timestamp, 
unique (DCODtarget, DCODIoHandle)); 

update tables set table_ower = 'nsadmin' where table_name = 
1 DCObjectDestinations' ; 



Fig. 31 



create table Indexes 
(IndexlD int not null, 
IndexDescription text not null, 
IndexBaseType int not hull, 
IndexParentID int not null, 
indexAbbrv text not null, 
unique (IndexlD)); 

update tables set table_ower = 'nsadmin* where tablejiame = Indexes'; 
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Fig. 31a 



create table Channels 
(ChannellD int not null, 
ChannelName text not null, 
Channel Description text not null, 

unique (ChannellD)); - - 

update tables set tab1e_owner= nsadmin 1 where table_name='Channels'; 



Fig. 31b 



create table ChannelContent 

(CCchannellD int not null, 

CCcontentID int not null, 

CCtype text not null, 

CCsource text not null, 

unique (CCchannellD, CCcontentID)); 

update tables set table_owner= , asadmin*where table_name='Channelcontenf ; 



Fig. 31c 



create table ChannelTemplates 
(CTchannellD int not null, 
CTtemplatelD int not null, 
CTattributes text not null, 
CTsources text not null, 
unique (CTchannellD, CTtemplatelD)); 

update tables set table.owner^nsadmin'where table_.name='ChannelTemplates*; 
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Fig. 32a 



create table WorkGroup 
(WGgroupID text not null, 
WGname text not null, 
WGmembership text not null, 
WGcommunity int not null, 
unique (WGgroupID)); 

update tables set table_ower = 'nsadmin' where table_name = 'Workgroup'; 



Fig.32b 



creat table WgroupContent 

(WGCgroupID text not null, 

WGCtypetext not null, 

WGCsourcelD text not null, 

unique (WGCgroupID, WGCtype, WGCsourcelD)); 

update tables set table_owner= 'nsadmin' where table. 
name= WgroupContent' ; 
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Fig. 33 



create table WGroupBaseContent 
(WGBCgroupID text not null, 
WGBCindexlD int not null, 
unique (WGBCgroupID, WGBCindexlD)); 

update tables set table_ower = 'nsadmin' where table_name = 
'WGroupBaseContent 1 ; 



Fig. 34 



create table WGroupMasterUsts 
(WGMLgroupID text not null, 
WGMLmasterList large_text not null, 
WGMLtmeStamp timestamp, 
unique (WGMLgroupID)); 

create index WBMLindex 
on WGroupMasterUsts 
using btreee (WGMLgroupID); 

update tables set tab!e_ower = 'nsadmin' where tablejiame = 
'WGroupMasterUsts'; 



Fig. 35 



create table WGroupAdhocContent 
(WGACdestID text not null, 
WGACsourcelD text not null, 
unique (WGACdestID, WGACsourcelD)); 

update tables set table_ower = 'nsadmin' where table_name = 
'WGroupAdhocContent 1 ; 
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Fig. 36 



create table WG roup Author Members 
(WGAMauthorlD text not null, 
WGAMgroupID text not null, 
WGAMrestrict int not null, 
unique (WGAMauthorlD, WGAMgroupID)); 

update tables set table_owner = 'nsadmin' where table_name = 
' WG roup AuthorMembers'; 



Fig. 37 



create table WGroupViewMembers 
(WGVMgroupID text not null, 
WGVMviewerlD text not null, 
WGVMadmin int not null, 
WGVMattribute int not null, 
unique (WGVMgroupID, WGVMviewerlD)); 

update tables set table_owner = 'nsadmin* where table_name = 
'WGroupViewMembers 1 ; 



Fig. 38 



create table AddressBook 
(ABuserlD text not null, 
ABgroupID text not null, 
ABdestination text not null, 
ABattribute int not null, 

unique (ABuserlD, ABgroupID, ABdestination)); 

update tables set table„owner = 'nsadmin' where table_name = 'AddressBook'; 
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Fig. 39 



create table AuthorHights 
(AuthorlD text not null, 
AuthorlndexlD int not null, 
AuthorAttribute int not null, 
unique (AuthorlD, AuthorlndexlD)); 

update tables set table_owner = 'nsadmin' Where table_name = 
'AuthorRights'; 



Fig. 40 



create table Viewers 
(Viewer ID text not null, 
Full Name text not null, 
AdminFlag int not null, 
DefWorkGrpID text not null, 
Def Attribute int not null, 
Passwdtext not null, 
unique (ViewerlD)); 

update tables set table_owner = 'nsadmin' where table_name = 'Viewers'; 



Fig. 41 



create table WGContentListAttributes 
(WGCLAgroupID text not null, 
WGCLAIistNumber int not null, 
WGCLAattribKey text not null, 
WGCLAattribValue text not null, 

unique (WGCLAgroupID, WGCLAIistNumber, WGCLAattribKey)); 

update tables set table_owner = 'nsadmin' where table_name = 
'WGContentListAttributes'; 
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Fig. 42 



create table WGContentListCriteria 
(WGCLCgroupID text not null, 
WGCLCIistNumber int not null, 
WGCLCcontentType text not null, 
WGCLCcontentSource text not null, 

unique (WGCLCgroupID, WGCLCIistNumber, WGCLCcontentType, 
WGCLCcontentSource)); 

update tables set table_ower = 'nsadmin' where table_name = 
'WGContentListCriteria'; 



Fig. 43 



create table CSAdminMessages 
( CSAMIevel text not null, 
CSAMclass text not null, 
CSAMheading text not null, 
CSAMinfo text not null, 
CSAMtmeStamp timestamp not null); 

create index CSAMbyOID 
on CSAdminMessages 
using btree(oid); 

update tables set table_owner='nsadmin'where 
tablejname^CSAdminMessages'; 
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Fig. 44 



create table CSContent 

(CSCauthorlD text not null, 

CSCIinkOID oid, 

CSCheadline text not null, 

CSCfilename text, 

CSCinfo large_object not null, 

CSCtmeStamp timestamp not null, 

CSCoriginSite text not hull, 

CSCoriginOID text not null, 

CSCdataAttr int not null, 

unique (CSCoriginSite, CSCoriginOID)); 

createindex CSCbyOID 
on CSContent 
using btree(oid); 

up date tables set table_owner='nsadmin' where 
table_name= , CSContent' ; 



Fig. 45 



create table CSContentBase 

(CSCBcontentOID oid not null, 

CSCBindexValue int not null, 

CSCBindexTree text not null, 

CSCBIocked int not null, 

unique (CSCBcontentOID, CSCBindexValue) ); 

create index CSCBbyContOID 

on CSContentBase 

using btree( CSCBcontentOID ); 

create index CSCBbyOID 
on CSContentBase 
using btree( oid); 

up date tables set table_owner='nsadmin'where 
tablejiame^CSContentBase'; 
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Fig. 46 



create table CSContentAdhoc 

( CSCAcontentOID oid not null, 

CSCAdestination text not null, 

CSCAsource text not null, 

CSCAIocked int not null, 

unique ( CSCAcontentOID, CSCAdestination ) ); 

create index CSCAbtOID 
on CSContentAdhoc 
using btree(oid); 

create index CSCAbyContOID 

on CSContentAdhoc 

using btree( CSCAcontentOID ); 

update tables set table.owner= , nsadmin , where 
table_name= , CSContentlndexes'; 



Fig. 47 



create table CSDistributionQueue 
( CSDQsourceTableName text not null, 
CSDQsourceTableOID oid not null, 
CSDQsourceURL text not null, 
CSDQinsertTmeStamp timestamp not null, 
CSDQretrievalTmeStamp timestamp, 
CSDQtargets text not null, 
CSDQorigins text not null, 
unique (CSDQsourceTableName, 
CSDQsourceTableOID) ); 

create index CSDQbyOID 
on CSDistributionQueue 
using btree(oid); 
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Fig. 47a 



create tableCSReplicationQueue 
(CSRQsourceTableName text not null, 
CSRQsourceTableOID oid not null, 
CSRQsourceURL text not null, 
CSRQinsertTmeStamp timestamp not null, 
CSRQretrievalTmeStamp timestamp, 
CSRQtargets text not null, 
CSRQorigins text not null, 

unique (CSRQsourceTableName, CSRQsourceTableOID)); 

create index CSRQbyOID 
on CSReplicationQueue 
using btree(oid); 

update tables set table_owner=='nsadmin' where 
table_name= , CSReplicationQueue , ; 



Fig. 47b 



create table CSReplicationQueueDestinations 
(CSRQDdestld text not null, 
CSRQDrepQOID oid not null, 
CSRQDretrievalTmeStamp timestamp, 
unique (CSRQDdestID, CSRQDrepQOID)); 

create index CSRQDbyOID 

on CSReplicationQueueDestinations 

using bytree (oid); 

create index CSRQDdestldindex 
on CSReplicationQueueDestinations 
using btree (CSRQDestID); 

update tables set table^owner^nsadmin' where 
table_name='CSReplicationQueueDesti nations'; 
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DOMAIN COMMUNICATIONS SERVER 
BACKGROUND OF THE INVENTION 
Field of the Invention 

This invention relates generally to the field of networking 
computer systems and more particularly to the field of 
systems for providing control over distribution, 
redistribution, access security, filtering, organizing and dis- 
play of information across disparate networks. 

Background 

In most industries and professions today there is a rapidly 
increasing need for intercompany as well as intracompany 
communications. Most companies, firms, and institutions 
want to allow their employees to communicate internally, 
with other employees, and externally with .the firm's 
customers, vendors, information sources, and others 
throughout a work day. Depending on the nature of the 
information and the relationship between the parties, these 
communications may need to take the form of one-to-one 
communiques in some cases, one-to-many broadcasts in 
others, many to many communications, and even many-to- 
one communications. Some of these categories might also 
provide better information for all concerned if the flow of 
data is interactive and collaborative, allowing recipients to 
comment, share, and build upon what has already been 
received. 

At present it is both difficult and costly to achieve and 
manage high volumes of such communications easily, espe- 
cially if extremely sensitive, confidential or proprietary 
information must be selectively communicated not only 
internally, but externally to those companies considered 
business partners. 

In the financial industry, for example, an investment bank 
may want to communicate time -sensitive information to all 
of its investment management firm clients, and invite them 
to comment on it, while still insuring that the bank's 
competitors do not have access to the information. The 
investment bank may also want to receive news feeds from 
financial news services vendors on the same network that 
provides for the distribution of its proprietary information, 
as well as proprietary reports and analysis from other third 
party vendors it selects. 

A decade or two ago, the tools for handling such com- 
munications would generally have been limited to 
telephone, facsimile, overnight mail, or, more recently, 
electronic mail. Each of these media had limitations and 
drawbacks. Overnight mail is costly and for some types of 
information, much too slow. The telephone is, of course, 
much faster, but many telephone conversations are limited to 
one-to-one communications, since the telephone is a syn- 
chronous form of communication requiring the partes to 
communicate at the same time. This is not always efficient. 
For an investment bank to transmit a market analysis report 
to its clients on a one to one basis, the process is slow and 
cumbersome, and inevitably some clients would get the 
information long before others do. 

A telephone conference call insures that several clients get 
the same information at roughly the same time and a 
conference call is interactive, so that comments from various 
clients can be expressed. However, if the number of people 
on a conference call begins to exceed some critical mass, the 
call may be more confusing than helpful. The voices of other 
clients may be mistaken for that of the investment bank's 
analyst, for example. In either type of voice telephone 
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transmission of information, the recipient must take notes if 
he or she wants to remember details or go over the analysis 
later in the day. When information needs to be not only 
timely, but precisely and accurately recorded for later 
5 reference, voice telephonic conversation becomes less 
appropriate. 

Modern facsimile machines permit the broadcasting of 
information over telephone lines to a selected group of 
clients, as well as the transmission of charts and graphs and 

10 other images. This also gives the clients an accurate record 
to refer to later. However, facsimile transmission is not 
interactive, so any client comments that might have been 
offered are lost. Recipients of facsimile transmissions usu- 
ally have only a hard copy, not an electronic copy of the 

15 information, unless they use fax modems to receive. Thus, 
the utility to the recipient may be lowered significantly, 
particularly if such transmissions come into a common fax 
machine or mail room and take a few hours to reach the 
individual. 

20 Electronic mail sent over gateways between internal cor- 
porate networks is often slow, sent in plain text format (with 
any visual information usually sent as an attachment, if at 
all), and, like faxed data, is usually not indexed. As a result, 
finding the information that is wanted or needed in a stream 

25 of electronic mail messages can be tedious. Recipients may 
also be unable to use or see the attachments unless they use 
the same computer software and hardware. Many companies 
and institutions will not allow inbound or outbound attach- 
ments to email messages for security reasons. Email tech- 

30 nology is essentially a store and forward process that inevi- 
tably produces many copies of the same document on the 
same network — an inefficient use of network resources. 

After encountering these problems, companies and insti- 
tutions with private, internal distributed computer and tele- 

35 communication networks took another approach to address- 
ing intercompany communications. Many gave selected 
customers and vendors information from the company's 
own internal network, by building out a separate, isolated 
external network to communicate with their key business 

40 partners. Selected information from the company's internal 
network would be sent to the special external network and 
then sent on to the trading partners. This allowed larger 
documents and files to be transferred in a secure fashion to 
and from external sources. However, if an institution such as 

45 an investment bank wished to do this for all of its clients and 
all of its vendors, expenses and complexities increased 
dramatically. If the investment bank used one type of 
computer systems and network software for its internal and 
external networks, and a client or vendor used another, then 

50 individuals on both sides of the communication needed to 
have their network administrators configure their systems to 
work together and develop programs to provide security, as 
well as functionality. This usually involved capital outlays 
for computers, bridges(network devices that connect two 

55 networks using two different types of media — such as 10 
base T cable and FDDI connections), routers (special pur- 
pose machines that connect two or more networks and route 
messages to the correct internet protocol address), software 
and terminals, phis costs for developing software to handle 

60 the connections to and from the outside. To avoid extreme 
costs for equipment and special development, companies 
tended to restrict the number of companies granted this kind 
of access as well as the kind of information that could be sent 
or received. 

65 To provide affordable alternatives to direct connections, 
other companies, such as First Call Corporation offered 
networking and distribution services. For example, if an 
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investment bank wanted to deliver its research to its clients, 
First Call would deliver it for a fee, and also charge the 
recipients who received it. While this eliminated the need for 
intense capital expenditures and development costs on the 
part of both sellers and buyers of the information so 
distributed, it also effectively eliminated their control over 
the information, and its flow, too. First Call, for example, 
became a central source of information, not the bank or 
supplier, in the eyes of the clients. Since the information 
provided to First Call for distribution would be sent to all 
those who bought the service, it did not make economic 
sense for the providers to customize the information for any 
given recipient. Interactive communications were also 
impractical under this scheme. 

Then came the Internet — the worldwide system of linked 
computer networks that allows thousands of existing corpo- 
rate and institutional networks to communicate over it using 
standard communications protocols or signals. That aspect 
of the Internet known as the World Wide Web simplified 
these communications even more by providing what are 
known as hypertext links, and using HyperText Transport 
Protocol (HTTP) to allow a user to go from one hypertext 
link to another over the World Wide Web. (Hypertext is a 
way of creating and publishing text that chunks information 
into small units, called nodes, that have what are called 
hypertext links or anchors embedded in them. When a reader 
of the text clicks on a hyperlink, the hypertext software (also 
known as a browser or web browser) displays the node 
associated with that link. The collection of these nodes is a 
"web" and the Worldwide Web is a hypertext system that is 
global in scale.) With the Internet and the Worldwide Web, 
widespread disserriination of some types of information 
became simplified. However, most of the information pub- 
lished on the Internet's World Wide Web is not likely to be 
sensitive or confidential in nature, since access is readily 
available to many. 

Internal corporate networks may have highly confidential 
business files on the same computers that form the internal 
network, as well as extremely confidential technical and 
product tiles that may be vulnerable to attack and theft or 
misuse if a connection is made between the internal network 
and the Internet. Consequently, most companies construct 
"firewalls" between their internal networks and any gate- 
ways to the external world. (See FIG. 2, where companies 
CI through C9 are shown having firewalls Fl through F9, 
respectively.) A firewall is a security technique in which a 
user puts a specially programmed computer system between 
its internal network and the Internet. This special "firewall" 
computer prevents unauthorized people from gaining access 
to the internal network. However, it also prevents the 
company's internal computer users from gaining direct 
access to the Internet, since the access to the Internet 
provided by the firewall computer is usually indirect and 
performed by software programs known as proxy servers. 

Thus, if a user wants to get a file from a vendor, he or she 
would send an FTP (file transfer protocol) request to the 
firewall computer's proxy server. The proxy server would 
create a second FTP request, under its name and use that one 
to actually ask for a file outside the network. This allows the 
internal names and addresses to stay inside the company. 
Use of firewalls and proxy servers can slow performance 
somewhat, and also tends to limit the types of information 
that can be sent or received to that which is less likely to be 
sensitive or proprietary. 

The use of firewalls makes it less risky for internal 
network users to bring information in from the Internet and 
distribute it internally. However, once information is 
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brought inside a private corporate network, there can still be 
problems distributing it internally. 

Most large private networks are built of complex sets of: 
— Local Area Networks (LAN) — a set of computers 
5 located within a fairly small physical area, usually less 
than 2 miles, and linked to each other by high speed 
cables or other connections; and 
— Wide Area Networks (WAN) — groups of Local Area 
Networks that are linked to each other over high speed 
10 long distance communications lines or satellites that 
convey data quickly over long distances, forming the 
"backbone" of the internal network. 
These private internal networks use complex hardware 
and software to transmit, route, and receive messages inter- 
15 nally. 

Sharing and distributing information inside a corporate 
network has been made somewhat easier by using client/ 
server technology,' web browsers; and hypertext technology 
used in the Internet, on an internal basis, as the first steps 

20 towards creating "intranets." In typical client/server 
technology, one computer acts as the "back end" or server to 
perform complex tasks for the users, while other, smaller 
computers or terminals are the "front-end" or "clients" that 
communicate with the user. In a client/server approach the 

25 client requests data from the server. A web server is a , 
program that acts as a server function for hypertext infor- 
mation. In large private networks, a server computer might 
have web server software operating on it to handle hypertext 
communications within the company's internal network. At 

30 the web server site, one or more people would create 
documents in hypertext format and make them available at 
the server. In many companies, employees would have 
personal computers at their desks connected to the internal 
network. In an "intranet" these employees would use a web 

35 browser on their personal computers to see what hypertext 
documents are available at the web server. While this has 
been an advance for internal communications over a private 
network, it requires personnel familiar with HyperText 
Markup Language (HTML) the language that is used to 

40 create hypertext links in documents to create and maintain 
the "internal" web pages. If a more interactive approach is 
desired, an Information Technology (IT) specialist in some 
form of scripting, such as CGI, PERL, is needed who can 
create forms documents and procedures to allow users to ask 

45 for information from the server. 

Applications that need to share information internally can 
also use what is known as workgroup software such as 
IBM's Lotus Notes™ software on the internal network. 
However, this, too, requires special programming and script- 

50 ing for the unique needs of the organization. 

It is now increasingly common for intranets to connect to 
the Internet forming what is sometimes called an "extranet." 
The Internet, however, is essentially a passive transmission 
system. There is no automatic notification sent to clients or 

55 customers that a new report is available on a given Internet 
Web page that is external to the client's intranet. Customers 
or clients normally would have to search the Internet peri- 
odically to see if a Web page has changed, and if the change 
is something he or she is interested in seeing. Some Web 

60 page sites that provide fee services use e-mail to notify 
prospective users that the new data is available. As 
mentioned, e-mail is slow, so if the data is also time- 
sensitive, the notification may not reach the customer until 
later in the day, when it may be of much less value. 

65 One attempt to make the Internet more interactive has 
been offered by Intermind, namely a form of hypertext, 
called hypercommunications. In this approach, a number of 
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directories are built at various sites, in a fashion analogized 
to "speed dial buttons" on ordinary telephones. When a user 
wishes to get information from a site connected by 
hypercommunications, he or she "pushes" the "speed dial" 
button for that site, and is automatically linked to it, through 5 
directories created by the Intermind software. This approach 
also allows a publisher of information to poll subscribers to 
see if they are able to receive. If they are, and the publisher 
has new data to give them, the publisher "dials" his or her 
"speed button," thus sending the data. This helps solve the 10 
problem of notifying the customer that new information is 
available. 

However, making information produced internally avail- 
able selectively to external business partners via the Internet 
is an inefficient process if done manually by each author of IS 
internal information, even with such directories. Commin- 
gling internal information with external sources of informa- 
tion on the same intranet' is" also labor intensive and ineffi- 
cient if done manually, even with the "speed button" 
approach. This approach does not provide publication con- 20 
trol over the data, nor indexing nor organized presentation of 
the data. Nor does it solve the security problem posed by 
allowing others to access a website without a "firewall" or 
similar kind of access protection. 

Another option that became available to an information 25 
publisher after the advent of the Internet and Web browsers 
was a form of connection over the Internet that provides 
secure access, but usually to a more limited set of 
information, through a "demilitarized zone" or DMZ, using 
encryption and secure sockets. Since each company would 30 
want to protect the privacy of the internal data on its 
network, each would have a firewall around its network with 
a "demilitarized zone" (DMZ) outside or as part of the 
firewall for each other company it wished to reach. As 
shown in FIG. 2b, for example, Company A's DMZ Dl 35 
might be located outside its firewall Fl between the firewall 
Fl and Company A's gateway Gl to the Internet. Within 
DMZ Dl, an area IC is shown as set aside for communica- 
tions to and from Company C. As can be seen in FIG. 2b, the 
DMZ's of each company that wishes to communicate 40 
directly and securely with others must be configured to 
identify the intended communicants. 

If a customer needs to get information from 20 different 
external publishing sources, it may need to make 20 different 
connections between its firewall and that of the publishers 45 
and obtain 20 different user identifiers and passwords. A 
simplified illustration of this is provided in FIG. 2. For 
purposes of illustration, if companies C1-C3 are competing 
investment banks, and companies C5 through C9 are their 
customers, with C4 being a news source, a greatly oversim- 50 
plified network configuration is shown that uses such a DMZ 
configuration. Notice that bank CI has DMZ's D4-D9 for 
the news source C4 and the five customers C5-C9. Cus- 
tomer C5 has DMZ's D1-D3 for each of the investment 
banks it gets data from, as well as for news source C4. As 55 
FIG. 2 shows, this approach results in a maze of connections 
P, and DMZ's, D. A simplified view of DMZ's is shown in 
FIG. 2b, where company CI has, in its DMZ Dl, an 
application that communications with company C3. Com- 
pany C2, has, in its DMZ D2, applications CI and C3 to 60 
communicate with company CI and company C3, respec- 
tively. 

The DMZ approach requires each customer to obtain 
different user identifiers and passwords to gain access to 
each other company's network. For each individual at each 65 
customer site, someone in the investment bank's informa- 
tion technology department must assign user identifiers and 
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passwords to each. This further requires elaborate network 
administration and maintenance. A setup such as this, in 
which the customers use Web browsers to gather informa- 
tion from a supplier's network, is called a "pull" model, 
because the customers still have to actively seek out the 
information. To simplify the administrative tasks as much as 
possible, it makes sense for the information publisher to 
generalize the information that goes out, so that it is sent in 
a one-to-many, or broadcast format. In this type of approach, 
one publisher may organize its information in one style, 
while another may structure its data quite differently. Thus, 
it becomes extremely difficult for the clients or customers to 
index or cogendy organize the data from 20 different pub- 
lishers. 

For the information provider to be more active, a "push" 
model of communication is desirable. That is, rather than 
wait for the customers to seek out information available on 
its network, the provider would like to" be able to notify the 
user that the data is there and send it out automatically. 
Workgroup software, such as Lotus Notes, was usually 
thought to be the better solution for this type of intercom- 
pany transmission. Unfortunately, this usually requires a 
significant amount of software development as well as 
administrative overhead. In the example of the customer 
who is getting reports and data from 20 different investment 
banks, the information that needs to be consolidated at an 
employee's desktop at the customer site usually arrives in a 
variety of incompatible formats. If the customer wants to get 
morning analyses from each bank, an information specialist 
at the customer site will probably have to find out what 
format is used by each sending bank, have the customer's 
programmers understand the network address schemes, as 
well as the protocols, packets, ports and sockets to be used 
for each bank, and then create or modify one or more Lotus 
Notes workgroup application programs at the customer's 
employee's desktop to convert the data into an internal 
format and bring it in. 

One attempt to address at least part of these problems is 
a technique known as "subject-based addressing technol- 
ogy" as described in U.S. Pat. No. 5,557,798 assigned to 
Tibco. Using this approach, and the example of the direct 
network to network connection via a DMZ, shown in FIG. 
2a, a publisher CI might set up a server at its site to publish 
information by subject. The customer C5, usually has a 
"client" application, in its DMZ D5. The client application 
denotes the set of messages to receive using human-readable 
subject names. Subject-based addressing can eliminate the 
need for the customer programmers to understand all the 
network address, protocol, packet, port and socket details, 
and even simplifies some of the modification that needs to be 
done to the workgroup software. However, it does not 
eliminate the need to configure conversion or translation 
layer software at the site to take a network feed, and to 
understand how the data that is transmitted is formatted, and 
the need to modify the workgroup software, such as Lotus 
Notes applications, accordingly. In fact, both subject-based 
addressing and workgroup software such as Lotus Notes 
usually require a significant amount of additional program- 
ming development work to be done by the users in order to 
work effectively. 

From the information publisher's perspective, a "push" 
model that relies on the private network-to-network connec- 
tion through firewalls, DMZ's and workgroup programs, and 
uses subject-based addressing still fails to address the dis- 
tribution control problem that may be vital to the publisher. 
If the investment bank CI of FIG. 2a provides a morning 
analysis as a subject, once the data crosses out of the bank's 
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network and is disseminated over the Internet, the invest- its DMZ are the information technology specialists, this can 

merit bank has usually lost all control of replication of the become a labor intensive chore or a bottleneck or both for a 

analysis. In most cases of subject-based addressing, the company that needs or wants to send a high volume of 

publisher will not even know which companies are consum- information outside selectively. Similarly, present security 

ing its information. 5 technology provides various encryption options (thus creat- 

Even if one set of programs is written to address publi- ing problems for standardization amongst companies) but 

cation control and dissemination at one customer site, such leaves such matters as identification up to the information 

as customer C8, (in FIG. 2d) for example, using either technology (IT) department at each company to manage, 

software such as Lotus Notes or subject-based addressing, it The IT specialists must assign user identifiers and passwords 

is not always simple or easy to adapt that set of programs to 10 to every external individual authorized to access information 

work with customer C9's network, or amongst several (authentication) in the company's DMZ. Presently this is 

different customer's networks. Once it becomes desirable or usually done by manual letters of reference and manual data 

necessary to send and receive information over the Internet entry of each business and individual, 

or a wide area network linking several different If, as mentioned, documents must be created using 

corporations, dissemination control becomes a very compli- 15 HTML, or special CGI (common gateway interface) scripts 

cated problem. also need to be created and maintained to put data into the 

As already mentioned, it is difficult to index or organize proper formats, all of this tends to place matters of policy 

information received from many* different sources so that it * and content management in the hands of IT department 

can be grouped the same way on every receiver's desktop. specialists, rather than in the hands of authors and viewers 

Some profiling or "filtering" systems (such as products from 20 of information. IT specialists within companies are being 

Individual or PointCast) gather data from public sources and overwhelmed by requests to add new users and individuals, 

filter or sift through them to select information tailored to an administer the types of data that can be transmitted and 

individual person's request, but these systems do not usually create maintain changes and updates to the scripts, 

control replication, nor do they allow any interaction with programs, networks and systems as a whole, 

the data. Profilers are usually one-to-many, one way distri- 25 It is an object of this invention to provide a universal 

bution models that do not allow any interaction. domain routing and publication control system that enables 

In corporations and large institutions with intranets, the selective transmission of valuable information in a 

where browsers are used, individual receivers of information manner that allows for control of replication and publication 

can organize what they see by keeping bookmarks. of the information. 

However, bookmarks are usually so customized that no two 30 It is another object of the invention to provide a system 
sets of them are likely to be identical. As with the external that can disseminate information selectively between dis- 
proving systems, intranets using browsers and bookmarks parate types of users and networks, 
are also usually only able to send information in one Still another object of the present invention is providing 
direction. A user at company C8 of FIG. 2 who gets the a system that allows users to comment on and interact with 
analysis provided by bank CI, usually cannot use a browser 35 the information received. 

to comment and reply, unless a special form sheet has been It is another object of the present invention to minimize or 

created by using CGI scripting or some other programming eliminate the need for software development by users and 

or scripting language for that purpose for that Web page, by information providers. 

bank CI. Again, custom programming or scripting adds to Another object of the present invention is reducing the 

costs and usually makes it difficult to standardize across 40 need for special administrative procedures and specially 

companies. trained personnel to manage the system. 

Most intranet systems connected to the Internet today do Still another object of the present invention is providing 

not allow an individual user to request information by both a system that allows users to access information at the 

source and subject, and most do not allow an individual user speeds of their internal networks the majority of the time, 

to act as both an author and a viewer of information. 45 Another object of the present invention is providing 

As FIG. 2a illustrates, connecting consumers of informa- dynamic distributed network resource registries that facili- 
tion over the Internet to external information sources via tates the standardization and organization of information by 
DMZ's and secure sockets is complex and cumbersome, as subject, source or a combination of both, 
well as costly to set up and administer for the publishers of „. „ „ , A „„ „ m ^ 
information From the viewpoint of the consumers of infor- so SUMMARY OF THE INVENTION 
mation over the Internet it should be noted that transmis- These and other objects are achieved by a domain com- 
sions over such a distribution model occur at "Internet munications server having a first computer with a disk for 
speed." That is to say, once a request for information leaves storing a dynamic client registry and for storing resource 
customer C8, for example, if it goes over the Internet it is in locators containing function names; a web server program 
TCP-IP formatted packets, and possibly encrypted via 55 which, when executed by the first computer, causes the first 
secure socket technology. In any case, its speed is the computer to respond to the resource locators by calling the 
average speed of the Internet transmission links, once it function name indicated into the first computer; a database 
leaves customer C8's backbone network. This is usually management program for organizing the d vnamic__client 
much slower than the speed of transmission within the r£gistryj_a domain communications server program which, 
customer's own internal network. Thus, performance speed 60 when loaded by the web server program in response to the 
of the intercompany communications can be problematic as appropriate resource locator is executed by the first corn- 
well, when seen from the consumer's viewpoint. puter and responds to resource locators directed to it and also 

While the use of DMZ's or devices such as proxy servers directs the database management program in organizing the 

help ameliorate the security problems, DMZ's also tend to dynamic client registry; a number of secondary computers in 

create content backlogs that form bottlenecks for all inter- 65 communications relationship with the first computer with a 

company communications. For example, if the only persons disk for storing a dy namic group regist ry in each and for 

authorized to transfer data outside the company's firewall to storing resource locators containing funcfi5n names in each; 
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the secondary computers also including a web server pro- FIG. 2b is a schematic diagram of private networks 

gram which causes the secondary computers to respond to communication externally over the Internet using prior art. 
resource locators by calling the function name indicated into FIG. 3 is a schematic diagram of the present invention 

the secondary computer, each secondary computer also showing several domains in communication with each other, 
having a database management program for organizing its 5 FIG 4 is a ^1^^ diagram of a client side communi- 

dynamic group registry; a client side communications server catioQS according lo me method aod a p para tus of the 

program for responding to resource locators directed to it, prc sent invention 

and for directing its database management program in - . , * . ... 

• • ^j - ■ * j . " FIG. 5 is a schematic diagram showing illustrative lnter- 

organizing its dynamic group registry; a domain communi- , _, . P , 

f. , * i - : * j • 11 „ * „ *t, * « n connections between a domain communications server and 

cations resource locator list stored in all computers that 10 , „ . . . 

causes predetermined functions to be selected for execution ^veral chent side communications servers according to the 

in the domain communications server in the first computer; method and apparatus of the present invention, 
and a client side communications resource locator list stored F 10 - ^ ™ a bIock diagram of an illustrative dynamic 

in all computers that causes predetermined functions to be client registry at a domain communications server according 

selected for execution in the client side communications is to the method and apparatus of the present invention, 
servers in each secondary computer so that communications FIG. 6b is a detailed block diagram illustrative of the 

between the first computer and the secondary computers fields of a dynamic client registry at a domain com muni ca- 

cause the selected functions to be executed dynamically in " tions server of the present invention, 
order to manage information communications between the FIG. 7a is a block diagram of an illustrative dynamic 

first computer and the secondary computers. Client side 20 group registry at a client side communications server 

communications servers use regis ter resource locators to according to the method and apparatus of the present inveo- 

register their presence with the domain communications tion. 

server. The domain communications server notifies a client mQ Jb ^ a delailed block diagram mustrative of the 

when information for it is available The client side com- m6& of g dynamic registr y at a client side commu- 

munications server receives the notification and copies the 25 nications xrvG[ of me present invention. 

information from the domain server to its local systems, ___ ... 

, . t . A A , 4 4 . „ . 4 , . FIG. 8a is a list of principal domam communications 

where it is distributed automatically to the users in the " * ~ 7,™, a j • c j 

various groups who have permission to receive it. Users who server uniform resource locators (URL s) used in a preferred 

haveredistributionauthorizarionmaycommentontheinfor- embodiment of the present invention, 
mation received and send it to the users and clients autho- 30 FIG * 8 * is a list of principal client side communications 

rized to receive comments, whether internal or external to server URL's used in a preferred embodiment of the present 

the user's institution. invention. 

It is an aspect of this invention that it allows a company FIG - 9 is a detailed layout of an illustrative domain clients 

to communicate securely with other firms outside its private Jkt according to the method and apparatus of the present 

network without requiring the use of DMZ's at any site. 35 invention. 

It is an aspect of this invention that it provides a dynami- FIG- 10 is a detailed layout of an illustrative client sources 

cally configurable domain routing and publication control lis* °f me present invention. 

system. FIG. 11 is a detailed layout of an illustrative client objects 

Another aspect of the present invention is that it enables ^ ^ °f me present invention, 
users to define and implement their own policies for distri- FIG. 12 is a detailed layout of an illustrative object 

bution and redistribution of information on a network. destinations list of the present invention. 

Still another aspect of the present invention is that it does FIG. 13 is a detailed layout of illustrative indexes accord- 
not require additional software development by users. ing to the method and apparatus of the present invention. 

Yet another aspect of the present invention is that it does 45 FIG. 14 is a flow diagram of startup procedures in a client 

not require additional skilled information technology per- side communications server according to the method and 

sonnel to administer the system, but instead, allows users to apparatus of the present invention. 

administer it themselves. FIG. 15 is a flow diagram of initialization of shared 

Another aspect of the present invention is that it makes it objects by a client side communications server according to 

possible for users in a private network to receive information 50 the method and apparatus of the present invention. 

from outside the network at the speed of the private network FIG. 16 is a more detailed flow diagram of initialization 

most of the time. of shared objects by the client side communications server 

Yet another aspect of the present invention is that it gives according to the method and apparatus of the present inven- 

information publishers a simple way to produce selective tion. 

distributions to various clients. 55 FIG. 17 is a flow diagram showing shared object initial- 

„ _ ^ nmr rt „ _ „„™„ ization by the admin server of the client side communica- 

BRIEF DESCRIPTION OF THE DRAWINGS tions ^ according tQ ^ method and apparatus of the 

FIG. 1 shows a schematic diagram of the present inven- present invention, 
tion showing a domain communications server and several 60 FIG. 18 is a flow diagram showing shared object initial- 
client side communications servers. ization by the tool server of the client side communications 

FIG. la is an alternative schematic diagram of the present server according to the method and apparatus of the present 

invention showing virtual connections between a domain invention. 

communications server and several client side communica- FIG. 19 is a flow diagram showing shared object initial- 

tions servers. 65 ization by the agent server of the client side communications 

FIG. 2a is a schematic diagram of private networks server according to the method and apparatus of the present 

communicating externally over the Internet using prior art. invention. 
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FIG. 20a is a flow diagram showing the initialization of 
the dynamic client registry by the domain communications 
server according to the method and apparatus of the present 
invention. 

FIG. 20b is a flow diagram showing the creation of a 
group by the client side communications server according to 
the method and apparatus of the present invention. 

FIG. 21 is a flow diagram showing the initialization of a 
client side communication server according to the method 
and apparatus of the present invention. 

FIG. 22 is a block diagram of an illustrative user screen 
display at a desktop terminal for adding a user according to 
the method and apparatus of the present invention. 

FIG. 23 is a block diagram of an illustrative user screen 
display for entering a new user's account information 
according to the method and apparatus of the present inven- 
tion. 

FIG. 24 is a block diagram of an illustrative user screen 
display for authorizing content creation for a new user 
according to the method and apparatus of the present inven- 
tion. 

FIG. 25a is a block diagram of an illustrative user screen 
display for selecting content types according to the method 
and apparatus of the present invention. 

FIG. 2Sb is a block diagram of an illustrative user screen 
display for selecting content type according to the method 
and apparatus of the present invention. 

FIG. 25c is a block diagram of an illustrative user screen 
display for selecting distribution options for a user according 
to the method and apparatus of the present invention. 

FIG. 26a is a block diagram of an illustrative user screen 
display for authorizing redistribution rights generally 
according to the method and apparatus of the present inven- 
tion. 

FIG. 26b is a block diagram of an illustrative user screen 
display for authorizing redistribution rights more specifi- 
cally according to the method and apparatus of the present 
invention. 

FIG. 26c is a block diagram of an illustrative user screen 
display for assigning group access according to the method 
and apparatus of the present invention. 

FIG. 26d is a block diagram of an illustrative user screen 
display for assigning internal group access for a user accord- 
ing to the method and apparatus of the present invention. 

FIG. 26e is a block diagram of an illustrative user screen 
display for assigning external group access for a user 
according to the method and apparatus of the present inven- 
tion. 

FIG. 27 is pseudocode in SQL format illustrating the 
creation of a domain clients table. 

FIG. 28 is pseudo-code in SQL format illustrating the 
creation of a client sources table. 

FIG. 29 is pseudo-code in SQL format illustrating the 
creation of a client objects table. 

FIG. 30 is pseudo-code in SQL format illustrating the 
creation of an object destinations table. 

FIG. 31 is pseudo-code in SQL format illustrating the 
creation of an index table. 

FIG. 31a is pseudo-code in SQL format illustrating the 
creation of a channels table. 

FIG. 31b is pseudo-code in SQL format illustrating the 
creation of a channel content table. 

FIG. 31c is pseudo-code in SQL format illustrating the 
creation of a channel templates table. 
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FIG. 32a is pseudo-code in SQL format illustrating the 
creation of a workgroup table 70. 

FIG. 32b is pseudo-code in SQL format illustrating the 
creation of a workgroup content table. 
5 FIG. 33 is pseudo-code in SQL format illustrating the 
creation of a workgroup base content table. 

FIG. 34 is pseudo-code in SQL format illustrating the 
creation of a workgroup master list table. 
10 FIG. 35 is pseudo-code in SQL format illustrating the 
creation of a workgroup ad hoc content table. 

FIG. 36 is pseudo-code in SQL format illustrating the 
creation of a workgroup author members table. 

FIG. 37 is pseudo-code in SQL format illustrating the 
15 creation of a workgroup view members table. 

FIG. 38 is pseudo-code in SQL format illustrating the 
creation of and address book. table. 

FIG. 39 is pseudo-code in SQL format illustrating the 
2Q creation of an author rights table. 

FIG. 40 is pseudo-code in SQL format illustrating the 
creation of a viewers table 

FIG. 41 is pseudo-code in SQL format illustrating the 
creation of a workgroup content list attributes table. 
25 FIG. 42 is pseudo-code in SQL format illustrating the 
creation of a workgroup content list criteria table. 

FIG. 43 is pseudo-code in SQL format illustrating the 
creation of a client server administrative messages table. 
30 FIG. 44 is pseudo-code in SQL format illustrating the 
creation of a client server content table. 

FIG. 45 is pseudo-code in SQL format illustrating the 
creation of a client server content base table. 

FIG. 46 is pseudo-code in SQL format illustrating the 
35 creation of a client server ad hoc content table. 

FIG. 47 is pseudo-code in SQL format illustrating the 
creation of a client server distribution queue table. 

FIG. 47a is pseudo-code in SQL format illustrating the 
creation of a client server replication queue table. 

FIG. 47b is pseudo-code in SQL format illustrating the 
creation of a client server replication destinations queue 
table. 

DETAILED DESCRIPTION OF THE 
45 INVENTION 

FIG. 1 shows a preferred embodiment of the present 
invention in a schematic block diagram. A domain commu- 
nications server Al, is in communication with a number of 

50 client side communications servers CI through C9. Each of 
these client side communications servers is located behind 
the firewall F, of its respective corporate site in a preferred 
embodiment. That is, assume Company C-One has a client 
side communications server CI, Company C-Two has a 

55 client side communications server C2, and so on, through 
Company C-Nine. Temporary logical connections or "pipes" 
P are made between each client side communications server 
in this domain and the domain communications server Al. 
In a preferred embodiment, pipes P are connections formed 

60 over the Internet using conventional TCP-IP networking 
protocol and Netscape Corporation's secure sockets with 
encryption technology. However, as will be apparent to 
those skilled in the art, other networks and protocols and 
encryption techniques could be used as well. 

65 Still in FIG. 1, it can be seen that each client side 
communications server C has only one actual communica- 
tions pipe P with domain communications server Al. Yet, 
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depending on the way in which each client is registered with 
domain communications server Al, information may be 
disseminated from client side communications server CI to 
any or all of the other client side communications servers C2 
through C9. Thus, the present invention creates an intelli- 
gent extranet that links the community of companies C-One 
through C-Nine together over a network by means of 
domain communications server Al. 

The intelligent extranet that is created by the present 
invention allows each member client C to communicate with 
those companies or institutions external to it (which have 
authorized communicating with C) as though the other 
company were a part of the client's own internal network or 
intranet. In this sense, the invention creates a virtual com- 
munity of corporate intranets. 

To use a more specific example where the community of 
companies is in the financial industry, if CI, C2 and C3 are 
-client side communications servers for three different invest- 
ment banks, and C5 through C9 are client side communi- 
cations servers for investment management firms, while C4 
is the client side communications server for a news broad- 
cast organization, the investment bank at client side com- 
munication server CI is able, by communicating directly 
only with domain server Al, to send information to any of 
the others in communication with domain communications 
server Al. That is, if it wishes, the bank C-One at client side 
communications server CI can send its morning analysis 
reports only to client side communications servers C5 
through C9, at customers C-Five through C-Nine, while the 
news broadcast organization, C-Four, may broadcast its 
information to all the other client side communications 
servers communicating with domain communications server 
Al. Thus, a preferred embodiment of the present invention 
also works as a relationship information manager for the 
participating companies or entities in this community. The 
present invention thus allows the customers of investment 
bank C-One to receive valuable information in a timely way 
from a trusted advisor over a secure connection. 

Turning to FIG. la, some of the types of communications 
possible are illustrated. In this example, 4 different clients 
are shown, CI through C4. Client CI might be an investment 
bank located in Pennsylvania, USA, with only one client 
side communications server CI -PA acting as its "smart 
intranet/* according to the method and apparatus of the 
present invention. Client side communications server CI -PA 
is connected to the bank's internal Local Area Network 
Cl-Lan, which also includes two terminals, Tl and T2. 

As will be apparent to those skilled in the art, a terminal 
T could be any type of device capable of connecting to a 
network, such as a computer, a mini-computer, a 
workstation, a personal computer, a CRT terminal with 
keyboard, an internet-equipped television terminal, a key- 
board or touch screen and display device, a personal digital 
assistant, or any device that allows a user to communicate 
with a network and see information displayed. In a preferred 
embodiment, a personal computer capable of being con- 
nected to a network is used, together with standard Web 
browser software executing in the personal computer. 

In a preferred embodiment, the term "smart intranet" 
describes the way the present invention enables a company's 
internal network — its "intranet" — to perform information 
management (production, access and replication of 
information), on a one to one, group to group and site to site 
basis both inside the company as well as with participating 
companies external to it. 

Still in FIG. la, client C2 might be an investment bank C2 
that has offices in Hong Kong, New York and London, all 
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connected with each other through the bank's wide area 
network C2WAN to form an internal network. The bank's 
entire network is shielded from external intrusion by firewall 
F2. Each of investment bank C2's sites at Hong Kong, New 

5 York and London has its own Local Area Network — C2- 
HKLan in Hong Kong, C2-NYLan in New York, and 
C2-LNLan in London, with terminals T using standard 
commercially available Web browsers also connected at 
each Local Area Network. 

10 As shown in FIG. la, each site of client C2 has a client 
side communications server (C2-HK, C2-NY, C2-LN) con- 
nected to its Local Area Network, and thus to client C2*s 
Wide Area Network, C2WAN, forming for client C2 a smart 
intranet, according to the method and apparatus of the 

15 present invention. 

Similarly, client C4 has multiple sites connected by a 
Wide Area .Network behind a firewall.. to „: form its smart 
intranet, while client C3 has only one site, its Boston 
location, in communication with domain communications 

20 server Al as its smart intranet. 

Still in FIG. la, it can be seen that logical or virtual flow 
of smart intranet communications at client C2 are shown by 
the dotted line "pipes" P2 connecting each LAN inside client 

25 C2. The term pipes is used here to denote a logical connec- 
tion managed through software, not necessarily a physical 
one created by hardware. As will be apparent to those skilled 
in the art, there are many ways in which the Local Area 
Networks within a client can be physically connected to 

30 each other over a Wide Area Network to form an internal 
network 

In a preferred embodiment of the present invention, as 
shown in FIG. la these logical internal connecting pipes P2 
also exist outside client CI, and extend to domain commu- 

35 nications server Al, and through it, to clients CI and C3, but 
not to client C4. That is to say, in a preferred embodiment 
of the present invention, a client such as client C2 can 
communicate logically (through the present invention) with 
designated external sites as though they were internal to it or 

40 part of its own smart intranet and vice-versa. Yet Client C2 
has not lost any of the protections afforded by its firewall F2, 
since client C2 makes no physical connection with any of 
these external sites except domain communications server 
Al. In a preferred embodiment, all physical transmissions 

45 between client C2 and domain communications server Al 
take place over the Internet using Netscape Corporation's 
Secure Socket Layer (SSL) technologies and encryption. 

Still in FIG. la, it can be seen that each client C, has its 
own "pipe" P, ranging from PI through P6, as indicated in 

50 the legend 00. For example, the three sites at client C2 
communicate with each other internally over "pipe" P2. In 
a preferred embodiment of the present invention, client C2 
also seems to communicate over pipe P2 with clients CI, C3, 
and C5 while, in fact, client C2 has only one actual pipe 

55 connecting it to domain communications server Al. As will 
be apparent to those skilled in the art, this single pipe 
between client C2's network and domain communications 
server Al could also be implemented as a direct physical 
connection, if desired, using H or T3 high speed lines. The 

60 present invention allows client C2 to communicate exter- 
nally with clients CI, C3 and C5 through domain commu- 
nications server Al over a set of "virtual pipes" VP2. The 
term virtual pipe is used here to indicate that communication 
occurs as it would if two (or more) clients were in direct 

65 communication with each other over the Internet (or other 
network), when, in fact, each client is communicating physi- 
cally only with a domain communications server and is only 
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in "virtual" communication with the other clients or firms. 
The virtual pipes are created and managed dynamically by 
the logic of the present invention's domain communications 
server working with the client side communications servers 
at each site. Hence the term, intelligent extranet. 

Still in FIG. la, note that domain communications server 
Al acts as the primary domain communications server for 
the clients shown, but is also connected to regional or 
alternate domain communications servers A2 and A3. 
Consequently, if the computer systems or the physical 
communication links to the primary domain communica- 
tions server Al should fail for any reason, in a preferred 
embodiment of the present invention, communications can 
continue through use of an alternate domain communica- 
tions server A2 or A3. In a preferred embodiment of the 
present invention, domain servers keep each other up to date 
by automatic replication of all relevant tables and data, thus 
acting as mirrors to each other. 

As will be apparent to those skilled in the art, different 
domains could also be linked to each other by having a hyper 
or super domain communications server that maps a com- 
munity of domain communications servers together. 
Similarly, the domain routing of the present invention can 
also be used internally to create additional domain commu- 
nications servers to offload workloads from each other in 
large internal networks. For example, companies having 
client side communications servers at several locations in 
the US and in Europe, might choose to have the European 
client side communications servers connect to a domain 
communications server in Europe which is mapped into a 
corporate domain communications server in the US, which, 
in turn, might be mapped into external domain communi- 
cations servers as described above. Using domain commu- 
nications servers internally to offload work can improve the 
response time and throughput throughout the network. 

Turning now to FIG. 3, multiple connections of domain 
communications servers are shown. Here domain commu- 
nications server Al, which may be acting as the primary 
domain communications server for a network of clients, can 
also be an alternated domain communications server for the 
networks controlled by domain communications servers A2 
or A3 or both. Alternatively, domain communications serv- 
ers A2 and A3 might be regional domain communications 
servers for a single network controlled by domain commu- 
nications server Al. 

With reference now to FIG. 4, a preferred embodiment of 
the present invention is depicted schematically. As shown in 
FIG. 4, at a client C8*s Boston location, C8-BO, a computer 
20 is shown connected to domain communications server Al 
from behind firewall F8, and also to client C8*s Local Area 
Network C8Lan. In a preferred embodiment of the present 
invention, America Online Corporation's standard Web- 
server software WS, known as AOLserver™ is installed at 
computer 20 to handle TCP-IP communication protocols 
between computer 20, firewall F8, and the Internet as well 
as client requests from the browsers BR on the terminals 
T1-T4. 

As will be apparent to those skilled in the art, any 
Webserver software or similar program that handles general 
communications protocols and transport layer activities 
could be used as appropriate for the network protocol in use. 
Similarly, database management software DBMS, DBMS8 
in this example, is used to store and maintain a client side 
dynamic group registry 07 located on local electronic stor- 
age media such as disk 08 connected to computer 20. In a 
preferred embodiment, the Illustra™ object-oriented rela- 
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tional database software supplied by Informix Corporation is 
used, since this allows the use of object-oriented relational 
technology. However, as will be apparent to those skilled in 
the art, any commercially available database management 

5 software could be used to store and maintain data in client 
side dynamic group registry 07 stored on disk 08. Similarly, 
any of a number of electronic storage media could be used 
instead of disks. For example, in computers having sufficient 
random access memory, internal memory could be used as 

1Q the electronic storage media. 

Still in FIG. 4, a client side communications server CSS, 
here CSS8, is shown executing on computer 20 at client 
C8*s Boston site. In a preferred embodiment, a client side 
communications server CSS is used at each customer or 

1S client's site to serve all content produced internally, by the 
client, and also to handle reception of all content distributed 
from outside the client but within the domain served by 
domain communications server Al. A client side communi- 
cations server for a given customer may be made up of more 

20 than one server executing on other computers 20, but, in a 
preferred embodiment, each server for that given client uses 
replication to insure that the appropriate authorized infor- 
mation at each site is the same. Mote that each customer is 
not necessarily authorized to have access to all the content 

25 in the domain. In fact, the present invention is specifically 
designed so that access to content throughout the domain 
can be directed and controlled. Also in a preferred embodi- 
ment a client side communications server CSS for a given 
customer must use a domain communications server to 

3 q communicate with other customers that are external to it. 
Referring now to FIG. 5, a schematic diagram of several 
clients in communication with a domain communications 
server Al is shown. As can be seen, client C8 has the address 
of domain communications server Al on local disk 08 

35 coupled to client C8*s computer 20, in which client side 
communications server software CSS8 is executing. Note 
also in FIG. 5 that domain communications server Al 
includes a computer 20, and a local storage media, in this 
case, disk 40, having a dynamic client registry 06 stored in 

40 it. Also at domain communications server Al it can be seen 
that a conventional Webserver WS is executing in computer 
20, together with a conventional database management 
program DBMS. In a preferred embodiment of the present 
invention, domain communications server software DSS 

45 also executes in cooperation with Webserver WS and data- 
base software DBMS. It can be seen that domain commu- 
nications server software DSS maintains a list of all clients, 
C1-C8, in this case, that are part of this domain in dynamic 
client registry 06 on disk 40. 

50 In a preferred embodiment, web server WS is the 
AOLserver product from America Online, as it also allows 
the use of object-oriented technology. In open systems, such 
as Unix and similar operating systems, shared objects can be 
created in the C++ language. In the C++ programming 

55 language, a shared object is simply compiled code. 
AOLServer has the ability to dynamically initialize shared 
objects from URL's registered with the web server WS, so 
that those shared objects have callbacks. Which shared 
object to load is specified within an initialization file used 

60 when starting AOLServer's NSD process (the executable 
form of the AOLserver.) 

Similarly, the DBMS software used by domain commu- 
nications server Al in a preferred embodiment is the Illustra 
software mentioned above. Also in preferred embodiments, 

65 computers used as either domain communications servers or 
client side communications servers can be any of a number 
of commercially available types, from mainframes to mini- 
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computers to workstations or personal computers. Preferred 
embodiments of the present invention are designed to work 
with a number of existing installations as "middleware" — 
meaning software that does not replace or substitute for the 
existing operating system software or the typical basic 
communications software. Nor is it a substitute for applica- 
tions software, such as the web browser. Instead, it works in 
the "middle." 

In a preferred embodiment, the nature and extent of a 
domain can be determined by several different factors. 
Since, as shown in FIG. 5, the domain communications 
server can connect the intranets of several different compa- 
nies or institutions in ways that allow them to operate 
together very closely, it is anticipated that one company 
might operate the domain communications servers for an 
industry segment, while the companies that are part of that 
segment would have their own client side communications 
servers. In FIG. 5, for example, domain communications 
server Al might be a computer system for the investment 
banking industry segment of the financial industry, located 
at applicant's Assignee's corporate headquarters, while cli- 
ents C1-C8 might be investment banks and investment 
management firms. 

As will be apparent to those skilled in the art, however, the 
industry segment might be law or automotive manufacturing 
or pharmaceuticals, or any of a number of other major or 
minor industry segments. If the industry segment is 
automotive, for example, domain communications server Al 
might be operated by a service company, so that automobile 
manufacturers might be able to communicate closely with 
suppliers and dealers. Still using FIG. 5, in this example, 
clients CI and C2 might be competing automobile manu- 
facturers and clients C3-C5 might be major parts suppliers, 
while clients C6-C8 might be dealers. In a preferred 
embodiment of the present invention, manufacturer CI 
could communicate closely with suppliers C3, C4 and C5, in 
a secure fashion, while manufacturer C2, its competitor, is 
also communicating closely with them, as well. 

Still in FIG. 5, in a preferred embodiment of the present 
invention, it should be noted that domain communications 
server Al and client side communications servers C1-C8 
can each start up and shut down independently of each other. 
For example, the computer 20 which is part of domain 
communications server Al might be booted (started up) by 
itself, without any communication with the client side com- 
munications server. When that happens, domain communi- 
cations server Al initializes itself and checks to see if there 
are any messages for it. If not, it will wait until one is 
received. Each of the client side communications servers 
C1-C8, may have their computers boot at different times, 
too. For example, if client side communications server C8*s 
computer 20 is booted before domain communications 
server Al's computer is booted, client side communications 
server C8 initializes itself, and attempts to register itself with 
domain communications server Al, by sending messages 
containing the appropriate Uniform Resource Locators) 
(URL(s)) described below, for registration to domain com- 
munications server Al. If domain communications server 
Al has not yet been booted, these messages will be queued 
by client side communications server C8 and sent again 
later, in a preferred embodiment. As will be apparent to those 
skilled in the art, the registration messages could simply be 
regenerated at intervals, instead of queued. 

In a preferred embodiment, the URLs sent by the client 
side communications server and by the domain communi- 
cations servers usually contain at least the name of a 
function to be performed by the recipient, such as 
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registration, in this case. In many cases they also point to or 
include an object. 

Also in a preferred embodiment, client side communica- 
tions servers that are in the same firm or client can com- 

5 municate with each other, even if the domain communica- 
tions server Al normally used by that client is not active. 
Returning briefly to FIG. lfl, to illustrate this, for client C2, 
client side communications servers C2-HK, C2-NY and 
C2-LN can all communicate with each other inside client 

10 C2's Wide Area Network C2WAN even when domain 
communications server Al is not yet operational. 

That is, internal users and groups that have been estab- 
lished according to the method and apparatus of the present 
invention and authorized to create and view content can 

15 communicate with each other using the present invention 
and its organizing and indexing features even when domain 
communications server Al is offline or down. Messages that 
would normally have been sent by the client side commu- 
nications servers at client C2 to domain communications 

20 server Al are queued and sent whenever domain commu- 
nications server Al is started up. As will be apparent to those 
skilled in the art, other methods of providing for the com- 
munication between the client side communications servers 
and the domain communications server could be used, if 

25 desired, such as requiring the domain communications 
server to be operational before the client side communica- 
tions servers are allowed to communicate with each other. 
Client side communication server startup 
Turning now to FIG. 14, an overview flow diagram of the 

30 initialization of a client side communications server is 
shown. At step 400, the user initates the startup of a new 
client side communications server. At step 402 a server 
shared object is created, followed by client side server 
shared objects, admin server shared objects, tools server 

35 shared objects and agent server shared objects as created in 
steps 404, 406, 408, and 410, respectively. Once the shared 
objects have been created as shown in Step 412 of FIG. 15, 
processing continues. In FIG. 15, at step 414 the URL's used 
by the client side communications server (the principal ones 

40 of which are listed in FIG. Hb) are registered with web server 
WS. Next, workgroup objects are created at step 416. 

Another view of this is shown in the flow diagram of FIG. 
16. As seen there, at step 420, a client side communications 
server is initialized, then, at step 422, it registers its URLS 

45 with the web server WS executing on its computer 20. At 
step 424 the client side communications server calls the 
Register function on the domain communications server. At 
step 426, the domain communications server calls the 
adhocContentProducers functions on the client side com- 

50 munications server, and then, at step 428, the client side 
communications server calls the Producers function on the 
domain server. Next, at step 430, the domain communica- 
tions server calls the adhocContentConsumers function on 
the client side communications server, and finally, the client 

55 side communications server calls the indexes function on the 
domain communications server. 
Domain communications server startup 

With reference now to FIG. 20a, a very simplified over- 
view of the initialization of the domain communications 

60 server is shown (more detail is provided below.) At step 500, 
the domain communications server initializes itself and the 
dynamic client registry 06. Next, the domain communica- 
tions server checks, at step 502 to see if there are any 
messages (such as requests to register coming from a client 

65 side communications server). If there are no messages, the 
domain communications server could wait until there is 
some activity. (As will be seen below, in a preferred 
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embodiment, the domain communications server actually specify, as shown in FIG. 26b, whether this redistribution 

checks periodically to see if client side communications right extends only to internal members on either a limited or 

servers are still active.) unlimited basis or to external members, on either a limited 

Still in FIG. 20a, if a message has come in, such as a or unlimited basis, 

request from a client side communications server to register 5 Next, turning to FIG. 26c, a sample screen display asking 

itself with the domain communications server, the domain whether the new member is to have access to any restricted 

communications server handles the message at step 504, in groups is shown. If the user said yes to that screen, FIG. 26d 

the manner indicated by the message itself, as described in shows how the user might be asked to specify to which 

more detail below. restricted groups the new member should have access, and 

Client side communications server dynamic group registry 10 also in what capacity — that is, as a viewer or a contributor 

Referring now to FIG. 20£>, a flow diagram depicting the or a redistributor or an administrator, or all or some com- 

process used by a client side communications server to bination of these. 

initialize or update the dynamic group registry 07 is shown. In FIG. 26e, a sample screen display asking the user to 

Starting at step 800, a user would give the group to be specify what kind of external group access the new user 

entered into group registry 07 a name, then, at step 805, 15 should have is shown. Relating back to the example of the 

indicate whether the access type for this group is to be financial community, it can be seen in the display shown in 

common or restricted (these terms will be described in more FIG. 26e that it is a very simple matter to "permission" a 

detail below.) Next, at step 810, the client side communi- * new member to create and distribute documents to other 

cations server checks to see whether this group will want participating companies — firms CI, C2 and C3. in the same 

base content (identified by subject), in which case at step 20 intelligent extranet. 

815 base content is selected, or adhoc content (identified by Once the user has finished answering the questions about 

source) in which case adhoc content will be selected. As adding a new member, the client side communications 

described in more detail below, other types of content are server completes the updating of the dynamic group registry 

also used in a preferred embodiment — mixed content and 07 to reflect these changes. 

nondecoupleable mixed content, as well as system content. 25 As will be apparent to those skilled in the art, a client side 

Processing for these is similar. As will be apparent to those communications server can be a self-sufficient entity, used 

skilled in the art, content can be grouped in any of a number simply to provide a much better and simpler intranet man- 

of ways without deviating from the spirit of the present agement tool inside a corporation than presently exists. The 

invention. client side communications server also acts as a powerful 

Still in FIG. 20b at step 825, the client side communica- 30 publications control. By simply answering the questions 

lions server configures a content list. In one preferred brought up on the screen displays as new members and 

embodiment, the client side communications server next groups are added to the client side communications server 

checks to see, at step 830, whether a rolling link format is the user is able to organize, index, and control more than 

desired or a fixed link one, and at steps 875 or 840 update ever before the creation and dissemination of information 

the content list to list a title and indicate the number of rows 35 amongst the individuals and groups known to the client side 

to display according to the format. Then, at step 845, the user communications server. 

indicates the subject and/or the source of the content to be Returning to the financial community example shown in 

displayed on this content list in this group in dynamic group FIG. la, if this client side communications server is installed 

registry 07. At Step 850, the user chooses the authoring at bank C2, (of FIG. la), which has branches in Hong Kong, 

members, at step 855 the viewing members and finally, at 40 New York, and London, it can replicate itself so that there is 

step 860, the user can review the group's configuration. a client side communications server C2-HK in Hong Kong, 

FIG. 21 is a flow diagram showing how the client side a client side communications server C2-NY in New York, 

communications server determines whether to create client and a C2-LN in London. The procedures described above 

side communications server shared objects (compiled C++ can be used to manage communications amongst all three 

code) to communicate with other client side communica- 45 internal sites in a way that provides organized, fast access to 

tions servers either inside (see steps 905 and 910) or outside the information created inside bank C2. As will be seen from 

(see steps 915 and 910) its own firm. the discussion of indexing below, a viewer in London can 

FIGS. 22 through 26 are block diagrams of the interactive ask for and see indexed information he is authorized to 

screen displays created by the present invention for use by receive, comment on it internally, and have those comments 

a browser BR at a terminal. These figures are illustrative of 50 reviewed by his peers in Hong Kong and New York, if he has 

the steps described above to create groups on the dynamic those kinds of redistribution rights, 

group registry 07 in a preferred embodiment of the present Now turning to FIG. 6a, typical client information kept by 

invention. FIG. 22, for example, shows how a user might a domain communications server Al in a dynamic client 

enter a new user's name, and FIG. 23 illustrates how account registry 06 is shown. Dyna mic client registry 06 incl udes a 

information specific to that user can be entered, such as 55 domain clients table 60 (here sfiown in abbreviatedlbrm), a 

username, and so on. domain clients sources list 66, domain client objects table 62 

FIG. 24 shows bow the client side communications server and domain client objects destination lis t 68 a nd an index 

begins the process of establishing authoring rights table 64, as well as a channels table 61, a channel content 

(described below in more detail.) FIGS. 25a and 25b illus- table 63, and a channel template table 65. A domain clients 

trate an example of one way of organizing content 60 table 60 lists all the client side communications servers 

geographically, by global region. As is indicated, the user is within the given domain. As noted above, a client may have 

asked to indicate his or ber selections for these choices. more than one client side communications server (for 

Next, in FIG. 25c, sample distribution options are shown. example, where the client has multiple sites across the 

Next, in FIG. 26a, the client side communications server world, as in the case of Clients C2 and C4 shown in FIG. 

allows the user to specify whether the new group member 65 la.) 

should have redistribution authorization (this is described Consequently, as shown in FIG. 6b in a preferred 

below in more detail.) If this is to be allowed, the user can embodiment, an entry in a domain clients table 60 of 
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dynamic client registry 06 includes, for each client server, might be the morning analysis prepared by an investment 
the unique client side communications server name 60a, an bank Cl-PA for its clients. At its simplest, object 62 might 
indicator 60b which shows whether the server is active or be in simple ASCII text format, or in the universally 
not, a unique firm identifier 60c, which indicates the name readable Adobe Acrobat™ PDF format, or in a format 
of the company or firm or client that owns this server, a firm 5 unique to a word processing program such as Microsoft 
logo 60e, which can be reproduced in visuals associated with Word ™ or C ° rel ' s ^PJ^™' or TT i ?? re T ad sh f ! La- 
this firm and a domain client side identifier 60f, which, in a gram such as Microsoft s Excel™ or IBM s I^tus 1-2-3™ 
preferred embodiment, is the server location within the spreadsheets. Similarly if a firm aheady has existing 
firm's intranet, which, when combined with the firm iden- formatted pages, these too can be objects. It should be no ed 
t .- £ , A ' . , A .„ u * ♦ that in a preferred embodiment of the present invention, the 
bfier field 60c, creates a unique key. As will be apparent to 10 ^ m ^ ^ th / communications can 

those skilled in the art, more or less or other urfonnatK>n for J aU ^ ^ be h format> For e le> m 

about each client side communications server could also be object might complex ^ a ^ ^ movie ^ 

included here, if desired. For example, m addition to a logo, saw ^ or a CAD/CAM VLSI drawing of a chip set or 

perhaps an address of the firm's Web Page on the World engineering drawings of an automobile under development. 

Wide Web could be included. Alternatively, a logo field or 15 \ a t h e i atter examples of CAD/CAM or engineering 

the hypothetical web page address field, for example, could drawings, which are also usually highly confidential, it can 

be eliminated without deviating from the spirit of the present be seen that the present invention allows a company such as 

invention. -«.--.--.. — ....... au t 0 motive [ manufacturer to enable its engineering 

Returning to FIG. 6a, in a preferred embodiment, each department to work very closely and yet securely with 
entry in the domain clients table 60 is linked to a domain 20 subcontractor engineering companies by exchanging and 
client sources list 66 (also shown here in abbreviated form.) annotating drawings as a project progresses. Since a pre- 
A domain client sources list 66 is a list of all connections ferred embodiment of the present invention uses secure 
between client side communications servers within the socket technology for transmission, objects that are trans- 
domain. Still in FIG. 6a, and using the automotive domain mitted will be encrypted by the secure socket technology, at 
example, if competitors Cl-PA and C2 are two of the 25 the providing client side communications server, and 
competing manufacturers and C3 is a parts supplier to both decrypted at the receiving client side communications server 
of them, then domain client sources list 66 might be struc- of only those clients authorized to receive them. In a 
tured as shown. At column 66a, unique firm identifiers, preferred embodiment, this encryption and decryption of 
DSCfirmlD's are listed next to each source DSCsourceFir- transmitted objects is an automatic byproduct of the use of 
mID in column 66b. Thus, company Cl-PA can receive 30 secure sockets technology and its equivalents or improve- 
content from itself, Cl-PA, as well as from supplier C3. Note ments. As will be apparent to those skilled in the art, other 
that company Cl-PA is not shown as being authorized to encryption techniques could be used instead of secure socket 
receive any source information from its competitor, C2. or similar technologies. For example, techniques such as 
Similarly, company C2 can receive source content from direct encryption using software such as PGP, which is based 
itself and from supplier C3, but not company Cl-PA. This 35 on the RSA encryption algorithms could be used, 
illustrates how the virtual pipes described above are formed. Still in FIG. 6a, domain client objects table 62 is shown 

Still in FIG. 6a, a domain client objects table 62 is shown, containing an ASCII text format report 62a, a slide presen- 

as well. The domain client objects table contains all distrib- tation 62b, a word processing document 62c, a movie 62o*, 

uted objects received by the domain communications server and multiple reports 62e. In a preferred embodiment of the 

from any valid client side communications server within the 40 present invention, objects are represented either as text or as 

given domain. Upon receipt of such an object, the domain files. Thus the first item, ASCII text format report 62a will 

communications server notifies all client side communica- be handled by the present invention as ASCII text. All the 

tions servers having authorized access to that object that an other objects in domain client objects table 62 are handled 

object is available to be retrieved. Each entry in the domain as files. In the case of the slide presentation 62i>, for 

client objects table 62 points to a different domain client 45 example, it is transmitted to domain communications server 

object destinations table 68 that lists all the client side Al as a file, and from there it is received by all the 

communications server sites that are authorized and destined appropriate client side communication servers as a file, too. 

to receive the domain client object. In a preferred When it is accessed by a terminal T at a client site, the 

embodiment, a domain client Iohandle is a large object terminal must have the appropriate applications program for 

handle within the domain client objects table 60 that points 50 viewing that type of file available either at that site or at the 

to the distributed content that will be sent to the client side server for that site. 

communications servers. Referring briefly to FIG. 6b, with So, if slide presentation 626 of FIG. 6a was created using 
a domain client object destinations table entry, the domain Microsoft's PowerPoint™ software, the viewer at the client 
client target table 68a lists all the server names of the client site must be able to use Microsoft's Powerpoint software at 
side communications servers to which this object is des- 55 his or her site to view the slides (usually this can be done by 
tined. The domain client received column 68c contains, for having a copy of the application software installed at the 
each targeted client side communications server, the time the terminal, if it is a computer, or on the server serving this 
object was received by the domain communications server. terminal). This is usually not a problem but an advantage, 
The domain client processed table 68a* contains, for each since for many business personal computer users there are 
client side communications server, the time the object was 60 commercially available products which have achieved near 
processed by the client side communications server. In a de facto standards status, such as word processors, spread- 
preferred embodiment, this field is initially set to Null and sheets and presentation software. As will be apparent to 
updated when the client side communication server retrieves those skilled in the art, the present invention allows the users 
the domain client object. to continue using these "standard" products and even spe- 
Returning again to FIG. 6a, in a preferred embodiment, an 65 dally developed software programs that operate on files, 
object can be any type of information to be transmitted to a This is significant for many users with a major investment in 
client. For example, in the investment banking domain, it existing application software and prior developments. 
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Still in FIG. 6a, an indexes table 64 is also shown as part 
of dynamic client registry 06. The indexes table 64 is used 
to organize the domain's content. The values of the indexes 
are the same for a given domain. As shown in FIG. 6a, 
illustrative indexes for the investment banking market seg- 
ment domain are shown, including Mortgage, Agency, New 
Issue, Research and other indexes that might describe the 
content of the domain in an orderly fashion. 

Referring now to FIG. 6b, an index entry is shown having 
an IndexID 64a, an IndexDescription 64b, an IndexBasetype 
64c, and an IndexParentID64d. Index \D64a is the unique 
identifier of the index. In a preferred embodiment, Index- 
Baseiype 64c is used to determine which type of format 
(text or file) is used as the default format for that index, but 
all content for that index can be of both types. IndexDe- 
scription 64b is the descriptive label applied to the index. 
And IndexParentID 64d is the IndexID of this entry's parent. 

Turning back to FIG. 6a again, in indexes table 64 it can 
be seen that Index 11, New Issue, is a "child" of index ID 1, 
Mortgage. And further, index 61, Education, is a child of 
New Issue. In a preferred embodiment, indexes can have as 
many levels as needed. 

Still in FIG. 6a, in a preferred embodiment, channels table 
61, channel content table 63 and channel templates 65 are / 
also created. In a preferred embodiment of the present [25 
inventio n a channel is a combmal iQnjof.varinus indexes. Fori 
example, one ch annej jn^LconsisLpi^all thejndexes-that 
are likely to cont ain hot news item s. Another channel might 
be compose9*of Ihose indexes that are most frequently used. 
As will be apparent to those skilled in the art, the number 
and content of such channel groupings might vary from 
industry to industry or over time. As can be seen, then 
channels table 61 is used to organize the domain's content 
into related categories. Th ese channels are then passed to 
client side_ communications ser v ers upon s tartup and are 
usejj_duringjheja^^ 

alternative preferred embodiment, this function can be 
included in the client side communications server or a client 
side communications server using a domain communica- 
tions server for internal purposes. — O 
£a With reference now to FIG. 6b, channels table 61 contains 
a channel id field 61a, a channel name field 61b, and a 
channel description field 61c. For hot new sjtejms, _a chan nel 
id of 1 jni ght be assigned, with a channe l name of ^H qU 
N ews Item s" aad.a-ch annel des cription such as "hot news 
f rom the New Issue . Mortgage and"Rese£rc£iB9exes2!-As- 
will be apparenLtcL those skiUeB'rnlBe^artT if the domain is 
in another ind ustry seg ment, such as automo bile 
ma Ma^tUre,lfie"ihdexes ano^fralTnels will refer to diff erent 
topics and com^ ations„ofZtopjcs. In a preferred 
embodiment, channel content table 63 is used to determine 
the content that makes up the channel. Again, in FIG. 6b, 
channel content table 63 contains channel id field 63a, 
channel content id 636, which is paired with the channel id 
field 63a to create a unique key, a channel type field 63c, 
which will indicate whether the content is base content or ad 
hoc content or other types (as described below), and a 
channel content source field 63d, which indicates one or 
more sources for the content for that channel. In a preferred 
embodiment, a channel template table 65 is used to organize 
the channel's content. E ach template contains a channe l 
tem plate id field 65a , a channel templa te field 65b, whic hjs 
p aired with channel tempIate~id"fie l d~65a~to create a unique 
key j^annel^emplate.attributes^fidd,65 c-which defines the 
attribut es of the co ntenUist^and-a-channel-template-sources 
fi elcl 65d, which refe xS-tQ-id-S Joimd,m.the,channeLcontent_ 
table 63. 



With reference now to FIG. la, illustrative structure and 
contents of dynamic group registry 07 of the present inven- 
tion are shown. In a preferred embodiment, dynamic group 
registry 07 is used at each client to handle all the content that 
5 is produced internally at that client as well as the content that 
is produced throughout the domain that is received by that 
client. As noted above, each client side communications 
server must use the domain communications server in order 
to communicate with another firms' s client side communi- 
10 cations server. 

As shown in FIG. la, the principal entry in client side 
dynamic group registry 07 is group table 70. Group table 70 
is a list of all groups that have been established within a 
particular firm or client. Note that, while the term workgroup 
may occur in the figure or this text, the term group is 
generally preferred and can be read interchangeably. A group 
is used to organize the type and source of the content (as 
specified in content table 90 and ad hoc content table 94) 
available to that group and creates the respective content 
lists for the group as information is received. CSContent 
table 90 organizes content by the object id 90a, the author id 
906, the content link object id 90c, the content headline 90d, 
the content filename 9Qf, the content information 90g, the 
content timestamp 90A, the content origin site 90/, the 
content origin object id 90/, and the content data attribute 
90fc. This is automatically added as it is produced to all 
groups that have requested that specific type of content. Ad 
hoc content table 94 organizes ad hoc content by the source 
of the information and is added to a group when the author 
30 (or publisher) directs the ad hoc content to that group. 

As can be seen in group table 70 of FIG. la, in a preferred 
embodiment there are two types of groups — common and 
restricted. A group that is common is accessible by all 
viewers within the client or firm and can only take base 
content. Restricted groups are viewable only by members of 
the group as specified in the workgroup view members table 
82. A restricted group allows for both base content and ad 
hoc content as well as other types of content that may be 
developed. Ad hoc content can only be added to the group 
by the group's author and publisher members (workgroup 
author members table 80 and workgroup view members 
table 82.) 

Still in FIG. la, in group table 70, it can be seen that in 
a preferred embodiment, all groups have a community, 
indicated in the field WGcommunity, in which they are 
"known." The community is used to 'advertise' to other 
groups within the firm or client. The community contains 
producers of content that is advertised either internally (to 
the firm or client only) or externally to the entire domain. An 
internal group is not known outside of the firm or client. An 
external workgroup is known inside, as well as outside, the 
firm or client. If a workgroup is set as a producer, by using 
a value of 2, in a preferred embodiment in the WGcommu- 
nity field of group table 70, the group is advertised as a 
source of ad hoc content for other groups. 

Still in FIG. la, in a preferred embodiment, groups that 
are solely internal to the firm or client are so indicated by 
using a 0 in the WGcommunity field of group table 70. As 
shown in group table 70, workgroup WG1, a firm wide 
60 group, is the only internal group listed in this particular 
example. External groups are indicated by the use of a 1 
value in the WGcommunity field of group table 70. In setting 
the values for the WGcommunity field, a preferred embodi- 
ment exclusive OR's the values to determine all choices. In 
65 a preferred embodiment, the WGgroupID's are always 
unique since they are composed of a firmid, a site id and a 
number. As will be apparent to those skilled in the art, any 
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of a number of ways can be used to create unique group or those skilled in the art, various other ways could be used to 

workgroup ids. indicate the attributes of a given member. 

Still in FIG. la, workgroup base content table 74 is used In FIG. la again, address book table 84 contains a list of 

to determine the base content the respective workgroup is group(s) to which a given author or publisher is permis- 

interested in receiving when such content is produced, either 5 sioned to distribute content as a member of the address book 

internally or externally. Base content is selected by the S rou P identifier ABgroupID. That is, ABgroupID is the 

content type, (the index value WGBCindexID) and can be umc * ue ID of the workgroup that has permissioned the 

received by both common and restricted workgroups. Upon indicated author or publisher to distribute the workgroup's 

receiving a particular content type, the workgroup's content c ™}™ { ' ™£ valu K e \^ *? the fl ^g 1 ? ° f 6 rcm P 

list headline eu dated 10 Address book destination field ABdestination con- 

ea nes are up . tains the firmID and the workgroup ID of the group to which 

Workgroup master lists table 76 provides descriptive text ^ mhor 0f publisQer caQ < g trf g ute mnt6 ^ 

information about the list. Address book attribute field ABattribute of address book 
And again in FIG. la, workgroup ad hoc content table 78 teWc ^ is> ^ a preferred embodiment, a Boolean value set 
is used to determine the ad hoc content the respective to true if the workgroup allows this author or publisher to 
workgroup is interested in receiving when such content is is ^ a note to the content, and to false if not. 
produced, either internally or externally. Ad hoc content is Remaining in FIG. 7a, author rights table 88 is used to 
determined by the source of the content as opposed to the d etermine the type of content a given author c aiLcreate. The 
index of the content. The sources for ad hoc content are table contains three fields: author identifier AuthorlD, author 
those groups that have "advertised" themselves, as described index identifier AuthorlndexID, and author attribute Author- 
above. Mixed content is a combination of both adhoc and 20 Attribute. In a preferred embodiment, the content type (as 
base content. indicated by the author attribute field) that an author can 
Also in FIG. la, workgroup author members table 80 create is determined by the firm or client This allows the 
contains the list of authors and the groups that have specified client to define and implement its own internal policies for 
they will allow this author to add ad hoc content to the SUCD matters, rather than obligating the firm to abide by 
respective group. The authors are chosen from the list of 25 policies established by others or the constraints^La par- 
authors within a firm or client. The groups are also from the facu *? r extern ^ A U authors m us^be^aUdv^e^ of 
list of groups within the firm or client. Entries into this table thefi nn or c lien t, 
will only exist for groups that have specified that they are ^preferred embodiment, aU authors have a minimum 
producers of new content In the example of the workgroup author attr * ute of f ernal broadcast for the specified con- 
author members table 80 shown here, there is a workgroup 30 tent ^ In a P referred embodiment, the possible values 
author identifier WGAMauthorlD. This field is linked to the are ' 
ViewerlD of the viewers table described below. A work- Internal Broadcast 0 
group author members group identifier WGAMgroupID Internal Selective 1 
identifies the unique group within this client to which this External Broadcast 2 
member belongs. This value is linked to the WGgroupID of 35 External Selective 4 

group table 70. These values are exclusive OR'd to determine all choices, 

In the example shown in FIG. 7a, the same author, tburns, in a preferred embodiment. As will be apparent to those 

is fisted as a member of workgroup 2 WG2 and workgroup skilled in the art, other ways of defining and implementing 

3 WG3. The field workgroup author member restrict such values could be used. 

WGAM restrict is, in a preferred embodiment, a boolean 40 Still in FIG. la, viewers table 86_ contains th e list of all 

value that is set to true if the author must have been v alid useis xrjrie^ejslk^agiven.client or. firm, Iffis table E^^ >- 

individually "permissioned" to send to each of the work- used to dpj^rmjp? if the ^spe cified user or viewerisa membe r, 

groups that consume this workgroup's content. If this value of the client's intranet and access to that client's intran et will 

is set to false, the author can send to any workgroup that o nly beaUo wed if the user or viewer is listed in this table , 

consumes this group's content. 45 Us ers or viewers entered in this table are allowed acces s to 

Still in FIG. la, workgroup view members table 82 all client oxiknijffojrkgrou ps that are comm o n, as spe cified 

contains the list of viewers for the workgroups. Only viewer in the WGmembership field oL group.table_70. 

members of a workgroup have view access to a workgroup's Turning now to FIG. 8a, and back to a discussion of 

content All viewer members of a workgroup are selected domain communications servers, a list of the principal 

from the list of valid viewers for the firm or client. A 50 domain communications server URLs is shown. As men- 

wofkgfoup administrator (as specified in the WGVMadmin tioned above, a domain communications server is 

field) is allowed to determine members and the attributes of implemented, in a preferred embodiment, using AOLserver 

any members for the group. Distribution of the group's software, beca use of its ability to dynamicallyUQad shared 

content is controlled by the viewer attribute field WGVMat- objects wheTT"s~pawning a virtual server In a preferred 

tribute. In the example shown here, viewers tm alone and 55 embodiment ot the~preseni invention, object-oriented pro- 

tburns of workgroup 2 WG2, are administrators for work- gramming techniques are used, since they allow the creation 

group 2 WG2. In a preferred embodiment, there are five of procedures for objects whose exact type is not known 

values that may be set for the viewer attribute field WGV- until actual running of the program. Object oriented tech- 

Mattribute. These are: niques also permit the system implementer to define and use 

Distribute None 0 60 shared objects — compiled C++ code that is called by more 

Distribute Internal 1 ° ne ^f™ ° r V^r«n- l " the AOLserver, for 

. example, which shared object toloa d is specified t o it within 

Distribute External 2 ; . an initializaTiolTflJi^ 

Distribute Internal Restricted 4 processTTnlTpreTerred embodiment of the present invention, 

Distribute External Restricted 8 65 t he shared ob j ect named 'domainserver.so * (also known as 

Also in a preferred embodiment, these values are exclu- 'domainserver.dlT for NT versions), is designated as the 

sive OR'd to determine all choices. As will be apparent to shared object to be loaded when the AOLserver is started up. 
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Id a preferred embodiment, the AOLServer Applications 
Programming Interface (API) is used because it is an inter- 
face which allows for the development of shared objects 
which can be loaded by AOLServer. The API is ANSI-C, a 
standard programming language interface and therefore 
requires C++ wrapper functions in order to bridge between 
the C based AOLServer and C++ based domain communi- 
cations server's objects. There are two wrapper functions 
defined by the domain communications server, named "go" 
and "stop". As will be apparent to those skilled in the art, any 10 
server or program which provides similar functionality 
could be used instead. 

The AOLserver NSD parent process, when starting any 
virtual servers, will look for a function named 
NS_ModuleIrrit which (per AOLServer documentation) 15 
must be defined for all shared objects that are loaded and 
contain any required start-up code. The domain communi- 
cations server of the present invention's Ns— Modulelnit 
function has two responsibilities, first to register the shut- 
down procedure "stop" that will be called by the parent NSD 20 
when shutting down secondly, to call the C++ wrapper 
function "go" which creates an instance of a DomainServer 
object. The shutdown procedure "stop" is responsible for 
cleaning up the DomainServer object initiated by calling 
"go". 25 

As described above, a domain communications server 
according to the method and apparatus of the present inven- 
tion is responsible for distributing and collecting content 
from various client side communications servers within its 
domain. It will also control which client side communica- 30 
tions servers may communicate with each other and act as 
"switching point". 

The creation of a domain communications server is all 
that is required by the wrapper function go( ). When creating 
a domain communications server object the following steps 35 
are taken: 

First the domain communications server saves local vari- 
ables that specify (among 10 other things) the "recognized" 
name of the virtual server and access to the underlying 
^database manager. 40 
tfy Next, th e available categories used by the domain to *' 
orga nize all of a domain's content are-loaded from the tab le 
Indexes, (see FIG. 6b) and are stored internally as Index 
Qgjects.^ 

Third, the domain communications server determines all 
vali d domain clie n ts t hat are known to be wi thin th is 
domain, their network addresse s, a nd wtiicli ~ clienjs can 
communicate with each_Qther — the virtual pipes (as shown 
in FIG7la".)~ValiB clients, client side communications serv- 
ers and their respective virtual pipes are found within the 
tables DomainCLients and DClientSources and are stored 
internally as DomainClient Objects. 
q r Fourth, the domain communications server will determine 
the pr edefined templates used by the domain's clients when 
creating new groups at the client side communications 55 
server sites. The se template s ar e used to organize the 
dom ain's Index O bj ects and network pr ojucers jntoji more 
organized_ format whe n_s^tjjigurpjyB 
cHenlTside^communicationS'- servers. The inform atioiTTdr 
these templates are found within the tables Channels, Chan- 60 
nel Content and ChannelTemplates shown in FIG. 6a and are 

sto red internally as Channel Objects . ; 

Lastly, the domain communications server will register 
with the AOLserver parent NSD process the URLs (Uniform 
Resource Locators) shown in FIG. 8, that the domain 65 
communications server will handle and the corresponding 
callback function in the domain communications server that 



the AOLserver parent NSD process should call when any 
such URLs arc requested. These registered URLs are used to 
communicate between the domain communica tions server 
and any valid client side communication server within the 
domain. Information is passed between client side commu- 
nications servers and the domain communications server via 
these registered URLS as a result. All information passed is 
in a form known in the art as "persistent objects" (i.e. objects 
that can restore themselves from stream form) and are 
retrieved and/or distributed via a respective URL. 

The following is a list of the URLs and allowable methods 
that are registered and the event class associated with each 
in a preferred embodiment: 



3 



45 



50 



URL 


Method 


Event Class 


/Register 


GET 


CSS Registration 


, /Indexes 


GET 


..CSS Registration 






and 






Registry Change 


/Consumer 


GET 


CSS Registration 






and 






Registry Change 


/Producers 


GET 


CSS Registration 






and 






Registry Change 


/Channels 


GET 


CSS Registration 






and 






Registry Change 


/Unregister 


GET 


CSS DeregLstration 


/Status 


GET 


Status 


/DistributeObject 


GET 


Content Replication 


/CollectObject 


GET 


Content Replication 


/Refresh 


GET 


Registry Change 


/Firm Logo 


GET 


CSS Registration 


/InternalServers 


GET 


CSS Registration 


Status/Reloadlndexes 


POST 


Status 


/Status/CSSStatus 


GET 


Status 



After startup, the domain communications server will 
thf.n^hcdtil e a timer p r ocedure 1° check every 60 seco nds 
the cu rrent status of each valid client side communicat ions 
serv er in its domain and "ping" those for which no act ivity 
has be en re cor ded within the last five minute s. In a preferred 
embodiment, a ping is simply a message requesting a status 
be returned from the client side communications server. 

An example of a domain communications server attempt- 
ing to ping a client side communications server might look 
like: 

https://vaHdCSS.com:84/Ping 
In response to this URL, the client side communications 
server in a preferred embodiment will return the HTTP 
status code 200 signaling the domain communications 
server. The pinging of a client side communications server 
will determine its current status and ensure that it is up, 
running, and registered with the domain communications 
server. 

If a client side communications server responds to a ping 
message the domain communications server will check to 
see if the client side communications server is already 
currently registered and if it is not, it will ask the client side 
communications server to attempt to register at this time (or 
re -register if the client side communications server has been 
running longer than the domain server). If the client side 
communications server is currently registered the domain 
server will note the last time it contacted this client side 
communications server and will not ping it again unless a lag 
of 5 minutes or more occurs before contact is reestablished. 
If the client side communications server does not respond to 
the ping, the domain communications server will note the 
client side communications server as not registered and will 
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attempt to ping this client side communications server every 
60 seconds until a response is finally returned. 

Once initialized, the domain communications server sim- 
ply responds to events that occur within the domain The 
domain communications server is responsible for verifying 
events as valid as well as notifying any client side commu- 
nications server of the effect of such event. This is done 
through the handling of the URLs specified above. 

The following is a list of the event classes and the 
corresponding actions that can occur within the domain: 
1. Client side communications server registration. 
The registration of a client side_communications server 



with the~domijn communicaTionsserver is started when the 
client side communications server reo 4 u^tethe^Regjster , * 
URL from its domain communicatig jis^seryer (theaddress of 
the domain communication server is found within the ini- 
tialization file used when starting the domain communica- 
tions server). In a preferred embodiment, the format of this 
URL is ^ "DomainServer:/Register?ID^CSS" where Domain 
Server is the protocol, machine name (and port) to request 
from and ID variable is the CSS's protocol, machine name 
(and port). Since the protocol is specified in this manner, it 
is trivial for the domain to use either standard HTTP or the 
SSL layer. In an alternative preferred embodiment, the 
present invention implements the X.500 Lightweight Direc- 
tory Access Protocol (LDAP.) 

An example of a client side communications server 
attempting to register might look like: 

https : //my Do m ainServe.com: 8 1/Register? I D=https:// 
validCSS.com:84 
The domain communications server will then verify thatjhe 



loc ation speci fied^y_JkgJ[ D isJa~vaTicr location ~_ foOhis 
domain by checking^ its internal collection o f DClient 
OgjegtsJ^Qa ded at startup ). If the request were validated, the 
domain communications server would return to the client 
side communications server the "virtual pipes" available to 
this client side communications server by passing a list of 
ClientSource Objects, from dynamic client registry 06. It 
can be seen that dynamic client registry 06 serves as the 
repository that enables the virtual community of intranets to 
be formed. 

In a preferred embodiment, validation requires that the 
domain communications server request the ContentProducer 
and ContentConsumer Objects from the registering client 
side communications server's site. The response from the 
client side communications server is the.siC£ajn^oxrn 
(stre ammg - is _ a n, inpu t/ou tpuL f oim a L f o r_d at abuse d in m os t 
op en system s) of the respective objects. The objects are 
r ecreated at the domain communications server and co l- 
le cted locall y. It is the domain communications server's 
responsibility to determine which ContentProducers and 
ContentConsumers are available to which client side com- 
munications server by checking with the list of "virtual 
pipes" already established. 

An example of the domain communications server 
requ esting a registering client side communications se rver 

https://validGS S.com :84/Adh ocCbnle,ntEmducers 
An example of the domain communications server request- 
ing the client side communications server for its Content- 
Consumer objects is: 

https://validCSS.com:84/AdhocContentConsumers 
In a preferred embodiment, the registering client side com- 
munications server will then request additional information 
about the domain using the other URLs handled by the 
domain communications server, as shown in FIG. 8a. All 
potential recipients are validated prior to returning any 
requested information. This information will include the 
following: 



The l ist of Index Objects used bv the doma in is requested 
b y tfagTndexes URL f06 jrf FKLSSndexOBi erisj^iised 
to organize content by subject matter (aSolcnown as~base 
content) vrithirTaHgiveErdom hosted centrally by 

5 the domain communications server in dynamic client regis- 
try 06. Index Objects are used by the client side communi- 
cations server as part of its dynamic group registry 07. 

The response to the Indexes URL 106 of FIG. 8a causes 
the domain communications server to iterate through its 
10 collection of Index Objects and return them in stream form. 
The stream form is translated back into Index Objects at the 
client side communications server site and collected locally. 

An example of a client side communications server 
requesting the indexes might look like: 
l5 https://myDomainServercom:81/lndexes?ID=https:// 
validCSS.com:84 
The list of InternalServer Objects is collected by request- 
ing the InternalServers URL 126 of FIG. 8a/ InternalServer 
Objects are used by a client side communications server in 
20 determining the sites of all other client side communications 
servers considered to be of the~same firm" and hence the 
client side communication server's responsibility to repli- 
cate to and from. 

The response to the InternalServers URL 126 causes the 
domain communications server to ask the validated Domain- 
Client to iterate through its collection of VirtualServerOb- 
jects and return them in the stream form . The stream form is 
translated back into InternalServer Objects at the client side 
communications server site and collected locally. Only those 
client side communications servers of same firms are 
returned (this includes the requesting client side communi- 
cations server as well). 

An example of a CSS requesting the internal servers 
might look like: 
^5 https://myDomainServer.com:81/InternalServers=https:// 
validCSS.com:84 — 
( The list of ContentProducer Objects is retrieved from the 
Producers URL 110 of FIG. 8a. ContentProducers are used 
by the client side communications server as part of the 
40 dynamic group registry 07 as available sources of adhoc and 
mixed content. ContentProducer objects contain the infor- 
mation about the producer and what it Produces. It is the 
domain communications server's responsibility to determine 
which ContentProducers are available to the requesting 
45 client side communications server by checking with the list 
of virtual pipes already established. 

The response to Producers URL 110 of FIG. 8a causes the 
domain communications server to return in stream form the 
ContentProducers available to the requesting client side 
50 communications server from all other client side communi- 
cations servers within the domain. For sites of multiple 
internal servers the stream includes internal producers as 
well. The stream form is translated back into ContentPro- 
ducer Objects at the client side communications server site 
55 and collected locally. 

An example of a client side communications server 
requesting the ContentProducers might look like: 

https://myDomainServer.com:81/Producers?ID=»https:// 
validCSS.com:84 
60 The list of ContentConsumer Objects is requested via the 
Consumers URL 108 of FIG. 8a. ContentConsumers are 
used by the client side communications server as part of the 
"domain registry" as to determine which of its producing 
groups have consumers requesting their content. r 
65 The response to the Consumers URL 108 of FIG. 8a 
causes the domain communications^ server to-, return in 
stream fon 



timers available to the request - 
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ing client side communications servers from all other client , 
side communications rvers~Asimitrtrie^om a in7ToTsites"o f 
multiple^intcmal'seryers tpfiZstrearn inclu de? interha l-'con- 



2. Client side communications server deregistration 

The deregistration of a client side communications server 
occurs when the client side communications server needs to 
notify the domain communications server that it will no 
longer be available to the domain. This event is controlled by 
the client side communications server and can occur at 



suming groups as well. The stream form is translated'back 
into ContentGonsumer Objects at the client side communi- 
cations server site and collected locally. 

An example of a client side communications server 1 ^ anytime, but, in a preferred embodiment, will always happen 

requesting the ContentConsumers might look like: , wnen me client side communications server attempts to 
h ttps://my DomainServer.com :81/Consumers?ID=htrp:/// shutdown normally. The client side communications server 
validCSS.com: 84 <io notifies the domain communications server of its desire to 

The list of ClientlnfoChannel Objects are collected via the unregister via the Unregister URL 104 of FIG. 8a. The 

Channels URL 128 of FIG. 8a. ClientinfoChannel objects format of this URL is Domainserver:/Unregister?ID=CSS" 

are used as templates for creating new groups at the client where Domain Server is the protocol, machine name (and 

side communications server. The InfoChannel object orga- port) to request from and ID Variable is the client side 

nizes portions of the domain's content into preconfigured 15 communications server's protocol, machine name (and 

views that ease the creation of a group at a client side port). 

communications server site. An example of a CSS attempting to deregister might look 

The response to the Channels URL 128 of FIG. Sa causes like: ' * " — — 

the domain communications server to return in stream form https://myDomainServer.com: 8 l/Deregister?ID-https:// 

the Infochannel objects available to the requesting client 2 o validCSS.com:84 

side communication server. The stream form is translated The domain communications server will then verify that the 

back into ClientlnfoChannel Objects at the client side com- location specified by the ID is a valid location for this 

munications server site and collected locally. domain by checking its internal collection of DClient 

An example of a client side communications server Objects (loaded at startup). If the request was validated, the 

requesting the Channels might look like: 2 5 domain communications server will return the HTTP status 

https://myDomainServer.com :81/Ch an nels?ID-https:// code 200 signaling the client side communications server 

validCSS.com:84 that it is now considered unregistered by the domain. All 

The list of Logo Objects are collected via the FirmLogo content destined for this client side communications server 

URL 116 of FIG. Sa. Logo Objects are used to further will be queued at the domain communications server until 

"brand** content with the originator. The registering client 30 the client side communications server becomes available for 

side communications server will request for any Logo the domain again. 

Objects it does not currently have a "current" Logo Object". In a preferred embodiment, deregistration of a client side 

Status of the Logo Object is determined from the list of communications server may also be initiated by the domain 

ClientSource Objects received from the Register URL 102 communications server This can occur when a client side 

of FIG. Sa. 35 communications server does not respond to the /Ping URL- 

The response to the FirmLogo URL 116 of FIG. Sa causes^, requested by the domain communications server when a 
the domain communications server to return m fUe form the_ | specified amount of time (usually 5 minutes) has expired 

corresponding LogoObject of the client side communica - ! since last contact from the client side communications 

tio ns server specifieHTTne object is sjored onjybeJocaJ JUe \ server. As will be apparent to those skilled in the art, shorter 

sy s^rjLand served ^whenever conten t that orig inated fro m 40 or longer time periods could be specified for this interval, 
t his source is viewed . ^ And similarly, while a preferred embodiment uses this 

An example of a client side communications server approach, and queues messages for the client side commu- 

requesting the LogoObjects might look like: nications server deregistered for this reason, it will be 

https://myDomainServer.com.81 /FirmLogo?ID=https:// apparent to those skilled in the art that other techniques 
validCSS. com:84&SRC=https//myCSS2.com.85 45 might be used to cause the messages to be held for the 
&Thc registration of a client side communications server will non-responding client side communications server, 
trigger the domain communications server to no tify all of th e In a preferred embodiment, the deregistration of a client 
other clien t side communications servers (having virtual side communications server will trigger the domain corn- 
pip es to the registering client side com munic ations servers ) munications server to notify all other client side communi- 
th at changes in the dynaj^client registry 06 ha ve occu rred 50 cations servers having virtual pipes to the deregistering 
th at maytre of in tcr ej ^rTtKeqa . This will cause 111 Registry client side communications server that changes in the 
Change events to" occur aTeach respective client side com- domain's registry have occurred that may b e of interest to 
munications server. The changes include the availability of then}. The changes include the unavailability of both addi- 
both additional consumers and producers found within the tional consumers and producers found at the deregistering 
registering client side communications server. The notifica- 55 client side communications server. The notification is done 
tion is done by requesting the /Refresh URL at each client by requesting the /Refresh URL at each client side commu- 
side communications server and specifying that both the nications site and specifying both the /Producers and 
/Producers and /Consumers have changed and should be /Consumers have changed and should be refreshed at the 
refreshed at the client side communications servers' conve- client side communications server's convenience, 
nience (see Registry Changes below for a detailed 60 3. Content replication 

description). This event occurs whenever content must flow from one 

In a preferred embodiment, registration is always initiated client side communications server to another client side 

by the client side communications server. However, also in communications sever within the domain. It should be noted 

a preferred embodiment, the domain communications server that in a preferred embodiment, the domain communications 

may ask any client side communications server at anytime to 65 server is only responsible for content replication between 

re-register when the domain communications server deems client side communications servers of different firms 

it appropriate. (external replication). Content replication between client 
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side communications servers of the same firm (internal 
replication) is handled directly between the two (or more) 
client side communications servers themselves. 
•A In a preferred embodiment, there are three types ofH 
^ content, Base Content, Adhoc Content, and Mixed Content, \5 
that can be replicated throughout the domain. (Also in a 
preferred embodiment, there is a fourth type of content 
known as SystemContent, but this type is not replicated). 
The type of content is determined by how the content is 
organized. Base content is content which is organized by 
topic or subject matter. The subject _matter must be de fined 
within oneor mojg^tahe^doriTairTs Index J3bjectsT"The 
orighT"*cTTEe~~content (i.e. where is was created) is not 
relevant. Base content may have more than one index 
associated with it. Adhoc content, on the other hand, is 
content which is organized by its origin and not its subject 
matter. The origin must be one or more of the "producing" 
groups at a given client side' communications server within" 
the domain. Mixed Content is a c ombina tion of bot hadhpc 
and bjts^conteigHNfi xed has both an origin and subject 20 
mat ter associatec Twith it- 

In a preferred embodiment, mixed content can be of two 
separate types, uncoupleable 'and decoupleable. Uncou- 
pleable mixed content is content that cannot be broken into 
its base and adhoc parts and must be treated as a whole, 25 
whereas decoupleable can be broken into its subcomponents 
and treated separately. The type of content is determined by 
the producing client side communications server at the time 
of content creation. 

The type of replication of content can be one of two 30 
possible modes, Broadcast or Selective Distribution, and is 
controlled by the client side communications server based 
on possible destinations permissioned to the producing 
individual at the client side communications server site. 
Broadcasting content has the effect of distributing the (base) 35 
content to all other client side communications servers 
within the domain in which that originating client side 
communications server has established virtual pipes. Selec- 
tive Distribution will only replicate (adhoc and/or mixed 
content) to the specified client side communications servers 40 
and not the entire domain. In a preferred embodiment, the 
type of replication specified dictates the type of content 
being replicated. That is, only Base Content can be broad- 
casted and only Adhoc and Mixed Content can be selectively 
distributed. 45 

Flow of content is controlled by the DistributeObject URL 
112 of FIG. Sa and the CollectObject URL 114 of FIG. Sa 
which are used to collect and distribute content throughout 
the domain. The type of content is not relevant to the 
replication process since only client side communications 50 
servers need to understand about its type (in order to process 
it) and the content is encapsulated within a 
DistributedObject, The DistributedObject consists of four 
parts, the origin, the target, the data, and the signature. The 
origin and targets are used by the domain communications 55 
server to determine who can receive the object, while the 
signature and data portions are used by the client side 
communications server to restore the object in order to 
process. 

In a preferred embodiment, replication is initiated by a 60 
client side communications server which has predetermined 
to distribute content externally. In a preferred embodiment, 
the client side communications server stores the Distribut- 
edObject locally and notifies the domain communications 
server that a DistributedObject is waiting for delivery at the 65 
client side communications server site. The client side 
communications server specifies a unique identifier to the 



DistributedObject that the domain communications server 
should use when collecting the object. The client side 
communications server does this through the DistributeOb- 
ject URL 112 of FIG. Sa. 

An example of a client side communications server 
attempting to notify the domain communications server to 
Distribute an Object may look like this: https:// 
myDomainServer.com:81/DistributeObject?ID=https:// 
ValidCSS. com:84&OID=3043.201e 
In response to the DistributeObject Url 112 of FIG. Sa, the 
domain communications server will return the HTTP status 
code 200 signaling the client side communications server 
that its notification was noted. After the notification is sent, 
the domain communications server requests the Distribut- 
edObject from the original client side communications 
server using the unique identity previously specified. This is 
accomplished by requesting the Collectobject URL 114 of 
FIG. Sa. 

Ad example of a domain communications server collect- 
ing a Distributed Object from a client side communications 
server might look like 

https://vaUdCSS.com:84/0)llectObject?OID=3043.201e 
The response from the client side communications server is 
the requested DistributedObject in stream form. The stream 
is captured by the domain communications server and 
recreated into a DistributedObject at the domain communi- 
cations server site. The client side communications server 
will note the time locally that the DistributedObject has been 
retrieved by the domain communications server for auditing 
purposes. After receiving the DistributedObject the domain 
communications server will determine the source and list of 
possible targets specified. The domain communications 
server will map the targets with those destinations with 
which the originating client side communications server has 
established a virtual pipe. The DistributedObject is then 
stored by the domain communications server locally in the 
DCObjects table 62 as shown in FIG. 6a, and each validated 
destination is stored within a DCobjectdestinatioos table. 
The domain communications server will then notify each 
client side communications server destination that a Distrib- 
utedObject is waiting for it This is done through the use of 
the ReceiveObject URL 212 of FIG. Sb, a client side server 
URL. A unique identifier for the specified DistributedObject 
is passed in the URL and is used by the receiving client side 
communications server when requesting the object. 

An example of a domain communications server notifying 
a client side communications server that a Distributed 
Object is available might look like: https:// 
validCSS.com:84/ReceiveObject?LOH=1010982029384 
In response to this URL the client side communications 
server will return the HTTP status code 200 signaling the 
domain communications server that its notification was 
noted. After the notification is sent, the client side commu- 
nications server requests the DistributedObject from the 
domain communications server using the unique identity 
specified. This is accomplished by requesting the CollectO- 
bject URL 114 of FIG. Sa. 

An example of a client side communications server 
attempting to retrieve a DistributedObject from the domain 
communications server might look like: 

http://myDomainServer.com:81/CollectObject?ID- 
https:/validCSS.com:84&LOH- 1010982029384. 
The response from the domain communications server is the 
requested DistributedObject in stream form. The stream is 
captured by the client side communications server and 
recreated into a DistributedObject at the client side commu- 
nications server site. The domain communications server 
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will note the time locally that the DistributedObject has been https://validCSS.com:84/Refresh?URWChannel 

retrieved by the client side communications server for In response to this URL the client side communications 

auditing purposes. After receiving the DistributedObject the server will return the HTTP status code 200 signaling the 

client side communications server will determine if further domain communications server that its notification was 

processing is needed and do so accordingly 5 received by the client side communications server. After the 

4. Dynamic client registry changes notification is sent, the client side communications server 

In a preferred embodiment, dynamic client registry 06, as will request the URL (with the required parameters) speci- 

shown in FIG. 5, is used to determine what resources are ^ the domain communications server, 

available within a given domain at a given point in time. 5 D omam Shutdown 

Dynamic client registry 06 consists of the following four 1Q eveat occurs> wnen the domain communications 

objects: content producers, content consumers, index must mtify all valid client side communications 

objects,andchannels.DynamicchentregisU-y()6isdynamic ^ ft ^ nQ { available. This notification is 

in nature, and changes to it are controUed by the domain handIed yia DomainS b u tdown URL 130 of FIG. Sa. 

communications server and can occur at any point in time. . , r , ... . 

rrn j * • • i_i c An example of a domain communications server notifying 

The domain communications server is responsible tor noti- . g r . . . ■ . 4 / 

fying all client side communications serverf of any changes. " a ch ™\ side communications server of the domain shutdown 

This is done through Refresh URL 118 of FIG. Sa. mi S ht Iook hke: 

In a preferred embodiment, changes to dynamic client https:/AralidCSS.com:84/DomainShutdown 

registry 06 occur as a result of four different events. The first In a preferred embodiment, notification is sent to the 

is the registering of a new client side communications server client side communications server to allow the client side 

within the domain. This will cause the domain communica- 20 communications server to begin queuing any content that 

tions server to notify all other "interested" client side must be replicated externally until the domain communica- 

communications servers of this new client side communi- tions server notifies the client side communications server 

cations server. Notification consists of the listing of Con- that it has once again become available. The client side 

tentProducers and ContentConsumers that the registering communications server may use an alternative domain com- 

client side communications server contains that are now 25 muni cations server (if one is specified when starting the 

available to all other existing client side communications client side communications server) until the original domain 

servers. It is the domain communications server's respon- communications server returns to avoid having to queue any 

sibility to determine which client side communications content. Upon return of the domain communications server 

servers see which producers and consumers (based on the to the domain, the client side communications server will 

established virtual pipes). In a preferred embodiment, a 30 notify the domain communications server of any content that 

client side communications server can selectively choose to is currently queued by initiating content replication (event 3 

notify only a subset of those the domain communications above). Notification of the domain communications server's 

server says are available. return is done by the domain communications server 

The second event causing a change in dynamic client requesting each client side communications server to 

registry 06 is the opposite of the first, namely the Deregis- 35 re-register (event 1). 

tration of a client side communications server. In either 5, Status 

event the domain communications server will notify all i n a preferred embodiment, events are . handled by the 

relevant client side communications servers of changes to domain communications sever in response to queries about 

both ContentProducers and ContentConsumers objects. the current Status of the domain and changes to those 

An example of a domain communications server notifying 40 portions of dynamic client registry 06 which are centrally 
a client side communications server of a change to dynamic hosted by the domain communications server (namely Chan- 
client registry 06, (specifically ContentProducers) might ne i$ and Index Objects). These events are not available to 
look like: any client side communications server but only to the 

https:/A^alidCSS.com:84/Refjresh?URL=/Producers domain communications server administrators. Status 

An example of a domain communications server notifying a 45 events will display the current status of all client side 

client side communications server of a change to dynamic communications servers within the domain. The status of a 

client registry 06 (specifically ContentConsumers) might client side communications server includes the currently 

look like: established virtual pipes to other client side communications 

https;//validCSS.com:84/Refresh?URL-/Consumers servers, the content producers (both internal and external) of 
The third type of change to dynamic client registry 06 is a 50 a client side communications server, and the content con- 
change in the IndexObjects used by the domain. This may sumers of a client side communications server (as well as 
only occur through the Status events (listed below) handled what the consumers are consuming). The domain commu- 
by the domain communications server. All valid client side nications server may be told to reload the domain's indexes 
communications servers are notified of this type of change or channels through these events. 

to dynamic client registry 06. 55 As mentioned, in a preferred embodiment, the system also 

An example of a domain communications server notifying uses a DistributedObject Object. The DistributedObject is 

a client side communications server of changes to dynamic used to replicate data from one client side communications 

client registry 06, (specifically IndexObjects) might look server to another within a given domain. The DistributedOb- 

like: https:/A^alidCSS.com:84/Refresh?URL=Indexes ject has four components that make it up: the origin, the 

The last type of change is a change in the Channels used by 60 target, the signature, and the data (the content) being repli- 

the domain. This may only occur through the Status events cated. The origin and target fields are set by the client side 

(explained below) handled by the domain communications communications server creating the data and evaluated by 

server All registered client side communications servers are the domain communications server when determining the 

notified of this type of change. possible destinations to which the data may replicate. The 

An example of a domain communications server notifying 65 signature is used by the receiving client side communica- 

a client side communications server of changes to dynamic tions server to reconstruct from the data its original type and 

client registry 06 (specifically Channels) might look like: to understand how to process it. A DistributedObject is 



11/15/2003, EAST Version: 1.4.1 



5,867,1 

37 

persistent, The origins and destinations are in the form of 
IdObjects. Multiple destinations and origins may be speci- 
fied. 

In a preferred embodiment, the IdObject is used to deter- 
mine the destination or source of the domain's content. It is 5 
made up of the firm, workgroup, and user identifications and 
is used by both the domain communications server and 
client side communications servers to determine the origin 
or targets for contents This object allows for wild card 
abbreviations to denote all possible matches and can deter- 10 
mine if a given IdObject is "equal to" another IdObject. 
Valid IdObjects are in the following form and sample wild 
card abbreviations for them are shown as: 



IdObject 


Equivalence 


*»* 


all users in all groups within all firms 


FIRM.".* 


all users in all groups at a specific firm. 


FIRM.GROUP.* 


all users in a specific group of a specific firm 


F1RM.GROUP.USER 


specific user is a specific group of a specific firm 
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As will be apparent to those skilled in the art, when multiple 
domain communications servers are used a domain field will 
be included in front of the firm field. 

In a preferred embodiment of the present invention, 25 
readership analysis and similar statistical information can be 
kept, if desired, about the use, copying, accessing or types of 
information referred to by users. As will be apparent to those 
skilled in the art, analysis programs to track other types of 
use, traffic flow, response times, and so on could also be 30 
implemented without deviating from the spirit of the present 
invention. 

In a preferred embodiment of the present invention, the 
system can also provide a distribution summary that, for 
example, allows a user to review at the end of a day, all the 35 
information sent out by the user at the end of a that day, or 
another time period. 

Also in a preferred embodiment, the system provides 
search features to allow a user to search for information 
based on the information's type or source or both, as well as 40 
such other factors as creation date, publication within a time 
frame and so on. As will be apparent to those skilled in the 
art, a number of differing search functions can be imple- 
mented without deviating from the spirit of the present 
invention. 45 

In a preferred embodiment, a producer object (which lists 
the firm name, the group name, etc.,) also lists the producer 
individuals with whom a receiving consumer can commu- 
nicate on a one to on basis. Similarly, the consumer object, 
amongst other items, includes a list indicating producing 50 
individuals to whom it is willing to talk on a one to one 
basis. This one-to- one communications facility of the 
present invention permits highly confidential communica- 
tions to occur on a one-to-one — "for your eyes only" basis, 
if desired. As will be apparent to those skilled in the art, 55 
various combinations and variations of this one-to -one 
relationship management are possible. 

Similarly, in a preferred embodiment a comment can be 
tagged with more than one index value. 

While a preferred embodiment of the present invention is 60 
implemented as a program written in the C++ programming 
language and operates on personal computers or worksta- 
tions using the NT or Unix operating systems, as will be 
apparent to those skilled in the art, other programming 
languages and operating systems could be used. 65 
Additionally, although the preferred embodiment uses a 
software program implementation, it will be apparent that 
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some or all of the logic of the present invention could also 
be embodied in firmware or hardware circuitry. 

Those skilled in the art will appreciate that the embodi- 
ments described above are illustrative only and that other 
systems in the spirit of the teachings herein fall within the 
scope of the invention. 

What is claimed is: 

1. A universal domain routing system comprising: 

a plurality of first computers each having electronic 
storage media for storing a dynamic client registry 
thereon and for storing resource locators containing 
function names thereon, each first computer further 
comprising a web server program which, when 
executed by each first computer, causes each first 
computer to respond to the resource locators by loading 
the function name indicated therein into a first 
computer, each first computer further comprising a 
database management program for organizing each 
dynamic client registry; 

a plurality of domain communications server programs 
which, when loaded by the web server program 
responding to the appropriate resource locator 
therefore, are executed by each first computer, and are 
further responsive to resource locators directed to each 
domain communications server program which directs 
each database management program in organizing the 
dynamic client registries to map inter-client and intra- 
client communications; 

a plurality of secondary computers in communications 
relationship with each first computer, each of said 
secondary computers having electronic storage media 
coupled thereto for storing a dynamic group registry 
thereon and for storing resource locators containing 
function names thereon, each secondary computer fur- 
ther comprising a web server program which, when 
executed by the secondary computer, causes the sec- 
ondary computer to respond to resource locators by 
loading the function name indicated therein into the 
secondary computer, each secondary computer further 
comprising a database management program for orga- 
nizing the dynamic group registries; 

a client side communications server program stored in 
each secondary computer, which, when loaded by the 
web server program responding to the appropriate 
resource locator therefor, is executed by each second- 
ary computer, and is further responsive to resource 
locators directed to the client side communications 
server program which directs the database management 
program in organizing the dynamic group registries to 
map inter-group and intra-group communications; 

a domain communications resource locator list stored in 
each first computer and each secondary computer that 
causes predetermined functions to be selected for 
execution in the domain communications server in each 
first computer; 

a client side communications resource locator list stored 
in each first computer and each secondary computer 
that causes predetermined functions to be selected for 
execution in the client side communications server in 
each secondary computer so that communications 
between a first computer and each secondary computer 
cause the selected functions to be executed dynamically 
to create an infrastructure for routing data using the 
maps contained in the dynamic client registries and 
dyamic group registries in order to manage information 
communications between the first and each secondary 
computer. 
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2. The apparatus of claim 1, wherein the domain com- 
munications resource locator list includes a register domain 
communications resource locator that causes the domain 
communications server program to direct the database man- 
agement program to dynamically register a client side com- 
munications server program in the dynamic client registry. 

3. The apparatus of claim 1, wherein the domain com- 
munications server program dynamically maps a plurality of 
other domain communications server programs so that they 
can selectively communicate with each other. 

4. The apparatus of claim 1, wherein the domain com- 
munications server program dynamically reconfigures the 
communications between the secondary computers in com- 
munication with it in response to resource locators request- 
ing such reconfiguration. 

5. A computer implemented method for universal domain 
routing comprising the steps of: 

storing a dynamic client registry in each of a plurality of 
first computers having electronic storage, and storing 
resource locators containing function names therein, 
each first computer further comprising a web server 
program which, when executed by each first computer, 
causes each first computer to respond to the resource 
locators by loading the function name indicated therein 
into a first computer, the first computer further com- 
prising a database management program for organizing 
each dynamic client registry; 

executing a plurality of domain communications server 
programs when loaded by the web server program 
responding to the appropriate resource locator therefor, 
for responding to resource locators directed to the 
domain communications server programs for directing 
the database management program in organizing the 
dynamic client registries to map inter-client and intra- 
client commurications; 

communicating with a plurality of secondary computers 
from the first computer, each of said secondary com- 
puters having electronic storage media for storing a 
dynamic group registry thereon and for storing resource 
locators containing function names thereon, each sec- 
ondary computer further comprising a web server pro- 
gram which, when executed by the secondary 
computer, causes the secondary computer to respond to 
resource locators by loading the function name indi- 
cated therein into the secondary computer, each sec- 
ondary computer further comprising a database mnan- 
agement program for organizing the dynamic group 
registry; 
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executing a client side communications server program 
stored in each secondary computer, when loaded by the 
web server program responding to the appropriate 
resource locator therefor, in each secondary computer, 
for responding to resource locators directed to the client 
side communications server program for directing the 
database management program in organizing the 
dynamic group registries to map inter-group and intra- 
group communications; 

storing a domain communications resource locator list in 
each first computer and each secondary computer for 
causing predetermined functions to be selected for 
execution in the domain communications server in each 
first computer; 

storing a client side communications resource locator list 
in each first and each secondary computer for causing 
predetermined functions to be selected for execution in 
the client side communications server in each second- 
ary computer so that communications between the first 
computer and each secondary computer cause the 
selected functions to be executed dynamically to create 
an infrastructure for routing data using the maps con- 
tained in the dynamic client registries and dynamic 
group registries in order to manage information com- 
munications between the first and each secondary com- 
puter. 

6. The method of claim 5, wherein the step of storing a 
domain communications resource locator list further com- 
prises the step of storing a register domain communications 
resource locator that causes the domain communications 
server program to direct the database management program 
to dynamically register a client side communications server 
program in the dynamic client registry. 

7. The method of claim 5, wherein the step of executing 
a domain communications server program further comprises 
the step of dynamically mapping a plurality of other domain 
communications server programs so that they can selectively 
communicate with each other 

8. The method of claim 5, wherein the step of executing 
the domain communications server program further com- 
prises the step of dynamically reconfiguring communica- 
tions between the secondary computers in communication 
with the first computer in response to resource locators 
requesting such reconfiguration. 
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